I'm trying to write a cross-platform program in c++ that will load certain modules (shared libraries) at runtime. To do this I'm using the ClassLoader from Poco C++ Libraries. I've written a compiling chain using autoconf, automake and libtool. This shouldn't be any problem in a Linux environment, but the problem occurs in Windows. I'm using MinGW and MSYS when compiling to be able to make use of my Makefiles. ClassLoader uses the Windows-specific LoadLibrary() function to load the modules, which means I have to compile them as DLLs.
The class that I compile to a library inherits another class within the main application. Then when I try to run make, it complains a lot about undefined reference and refuses to build a shared library. I guess this is because of the name mangling. Or is it because I can't inherit a class outside of the library? (That class is not included in the sources for the library, but the header file is found)
I'm not really sure how much trouble it's going to bring that I insist on compiling under MinGW + MSYS but still make use of LoadLibrary(). Anyone with experience of this?
Under Windows, a DLL must have all of it's symbols resolved when it's built. Under Unixes, you can leave things unresolved until load-time, and this behavior is currently incorprated into your design.
To change that, you will probably have to break out the base class in the main application (and everything else that the DLL depends on) into it's own DLL. That way, when you link your library that subclasses, it can link to the new DLL and fully resolve it's symbols.
The catch is, you have to be able to build this new DLL with all of it's symbols resolved.
Related
I'd like to build a Fortran program that will use a library with a specific interface, but I don't have the library currently installed on my system. I only need to compile the Fortran program, not run it. I assume that the system where my program is run will have the library installed in a standard location (i.e. /usr/lib).
Is this possible?
Specifically, I'd like to use the Conda-build system to compile a program that links to the MATLAB library (libmex). Since MATLAB is not installable with Conda or other package managers, I was hoping I could somehow build my program in such a way that it has the correct function call to libmex but requiring that users will have libmex installed in a place where my program can find it.
I have a library that I have developed and this library has some dependencies on other libraries. To be able to use this library in other projects, I need to provide a config.cmake. My question is, what do I need to put in my config.camke. Normally this config.cmake files have an INCLUDE_DIRS, LIBRARIES and EXECUTABLE variables as well as FOUND (and each one is properly set with the library, executables, and paths). However, I see that if I only give this when I try to compile the project depending on my library I get linking errors saying that the executable is missing the library that my library depends on. Is there a way that I can avoid this by doing a better config.cmake?
Thank you very much.
Given a Cygwin executable, how do i find out all the dll's that it depends upon?
For the libraries that are loaded by the system executable loader i can use a tool like depends (aka Dependency Walker), but i have no idea how to trace the dll's that the program tries to load dynamically with Load Library.
My aim is to be able to take the minimal dependencies of a program built for Cygwin platform in order to make it work portable, without all the Cygwin stuff that it is never gonna use (some base command line utils, man pages etc.).
Any help is appreciated!
Thanks to Michael Lockhart, the solution is simply to cygcheck the executable. Here are some references: on Wordpress and his site.
Two (quite old) libraries are written in C and originally compiled with MSVC 6. I want to change this and start using this with mingw.
Edit: the library looks to be using __stdcall calling convention.
So library 'a' is built first and a.lib and a.dll are produced including a.def by MSVC 6. Then library b is built and it uses library: a.lib.
I succeeded building a.dll with mingw. But I don't know how to build a.lib file ? Another requirement is that I need to do this entirely with MinGW tools or some other (free) solution.
Another question is will mingw libraries mix and match with msvc if we assume code is entirely done in C language? Thanks.
One thing that MinGW can do that MSVC can't do is link directly to DLLs - in other words, MinGW doesn't need an import library. Just pass the DLL as an input to the MinGW linker and that should be as good as using an import library.
In general, C language DLL exports should be usable by either MSVC or MinGW regardless of which tool created them. However there are corner cases which might not work correctly. Off the top of my head there are some differences in the ABI in how structures are returned and there might be some differences in how some floating point types are handled. Most DLL APIs that I've ever come across don't do either of these things, but there may be other corner cases I'm not thinking or aware of.
I'm creating a modular open-source library. Let's say the project has 15 .m files in it.
Should I (1) release it like the Venmo iOS SDK (Cocoa Touch Static Library) or (2) release it like JSONKit (just the source code)?
Releasing as source code means you, and your developers, don't have problems when a new architecture comes out. A static library built as armv6 wouldn't work with the latest Xcode today.
One caveat with source code releases, since you don't know what build settings the project it's added to will have, you'll need to do extra work to make sure it builds without warnings as best you can, even for pedantic warnings.
I prefer frameworks over static libs. Its easier to ship resources in the framework bundle if you eventually need to and there no cost to dynamic linking. If its pure C and the libraries dependencies are guaranteed to be there then it might be ok. But in general I try to avoid static linking unless I know the target OS has the exact dependencies for that binary at deployment time.
Its much easier to load a dynamic library with the endpoints you need at runtime (which were compiled for that exact platform but have the same external interface) than it is to fail with a static lib that was compiled directly to external dependencies which dont exist on the target platform.
Maybe Im crazy but this is what Ive always done in C, C++ or obj C. Just my opinion.
http://en.wikipedia.org/wiki/Static_library