[Решено][MinGW] Научите подключать правильную статическую библиотеку
Так, значит, ситуация такая. В одном каталоге скинуты все статические библиотеки, которые руками собирал. Среди них есть либы вида «libname.a» и «libname.dll.a», чтобы по хотению левой пятки я мог подключать либо статическую библиотеку, либо dll-ку.
Запускаю example.exe. Говорит, дай мне dll-ку. Что за дела? Я просил подключить «libname.a».
libname.a собрана правильно, отвечаю.
Значит, что я делаю. Я просто удаляю «libname.dll.a» из каталога с либами и выпулняю компоновку той же самой командой. Удаляю dll-ку, которую просило приложение из каталога с приложением. Запускаю. Никто ничего не требует. Значит подключилась «libname.a».
Внимание, вопрос. Я не хочу таким образом удалять и возвращать обратно «libname.dll.a». Научите, как сказать линкеру, мол подключи мне «libname.a», а не «libname.dll.a».
Можно «libname.dll.a» обозвать по другому. Ещё как-то можно? Я называл либы именно так, потому что все так делают (автосборка SDL, libpng, zlib и т. д.). Может я что-то не знаю об правильном именовании либ?
Ghost2
Либы опенсорсные. Но нету ни configure, ни Makefile.
Я всё-таки косячно собрал, да?
> Не линуксоид, поэтому имею право называть директории как угодно и использовать по любому назначению.
Это похвально. Тогда, чтобы быть последовательным, перенеси файлы этих библиотек к себе в проект.
Научите, как сказать линкеру, мол подключи мне «libname.a», а не «libname.dll.a»?
*.a файлы это статические библиотеки. *.dll.a это библиотеки импорта из dll.
> Научите, как сказать линкеру, мол подключи мне «libname.a», а не «libname.dll.a»?
Удали libname.dll.a
libxxx.dll.a
xxx.dll.a
libxxx.a
cygxxx.dll (*)
libxxx.dll
xxx.dll
before moving on to the next directory in the search path.
(*) Actually, this is not cygxxx.dll but in fact is
Вобщем, я извиняюсь. Долго пытался спросить у гугла и чё-то не получалось, поэтому задал вопрос здесь.
Olaf85
Да, я уже нашёл эту тему на Stackoverflow.
Вот ещё оттуда же:
In the past there were issues in MinGW with direct linking to *.dll, so it was advised to create a static library lib*.a with exported symbols from *.dll and link against it instead. The link to this MinGW wiki page is now dead, so I assume that it should be fine to link directly against *.dll now. Furthermore, I did it myself several times with the latest MinGW-w64 distribution, and had no issues, yet.
Источник
MinGW
The DLL we will build will consist of a single source file «example_dll.cpp»:
The following header «example_dll.h» declares the interface of the DLL, and is used both when building the DLL and when building an executable that uses the DLL:
Note that the three functions defined by the DLL have been declared slightly differently (for illustration purposes).
Building the DLL
To build the DLL use the following commands:
The import library created by the «—out-implib» linker option is required iff (==if and only if) the DLL shall be interfaced from some C/C++ compiler other than the MinGW toolchain. The MinGW toolchain is perfectly happy to directly link against the created DLL. More details can be found in the ld.exe info files that are part of the binutils package (which is a part of the toolchain).
Building a client executable
The following source code «example_exe.cpp» demonstrates calling the DLL’s functions:
To build the above example program, use the following commands:
It is worth mentioning that the same executable may be built without an import library using the following command:
If this method works for your application then there is usually no need for an import library.
Building and using a DLL without the dllexport/dllimport attibutes
There is an important thing to note with the above example functions:
Both hello(const char *) and Double(int) are surrounded by
in the header file. This has the rather important consequence that their exported names use C-style name mangling (i.e. their names are «as is»).
The function CppFunc( void ) is not inside an extern «C» <. >block and thus uses C++-style name mangling. This has the consequence that the exported name depends on the compiler used to generate the DLL. It is by design that such generated names are different from compiler to compiler.
The important and often overlooked consequence of this is that from the above DLL only the functions hello(const char *) and Double(int) are seamlessly callable from e.g. MS VC++ while CppFunc(void) is not (assuming the DLL is created by MinGW).
A similar statement goes for C++ classes exported in a DLL, i.e. for the class MyClass. For further reading search the Web for the keyword «ABI» and possible in conjunction with «C++». See also MixObjects.
Note: Someone else might want to provide more links here
A way to circumvent this problem is either using COM or create C-style wrapper functions to encapsulate the C++ ABI.
Источник
Linking to MSVC DLL from MinGW
I’m trying to link the LizardTech GeoExpress DSDK into my own application. I use gcc so that we can compile on for platforms. On Linux and Mac this works easily: they provide a static library ( libltidsdk.a ) and headers and all that we have to do is use them.
Compiling for windows isn’t so easy. They’ve built the library using Microsoft Visual Studio, and we use MinGW. I’ve read the MinGW FAQ, and I’m running into the problems below. The library is all C++, so my first question: is this even possible?
Just linking against the dll as provided yields «undefined reference» errors for all of the C++ calls (constructors, desctructors, methods, etc).
BTW: I have read the discussion below. It left some ambiguity as to whether this is possible, and given the MinGW Wiki page it seems like this should be doable. If it is impossible, that’s all I need to know. If it can be done, I’d like to know how I can get this to happen.
4 Answers 4
You can’t do this. They have exported C++ classes from their dll, rather than C-functions. The difference is, c++ functions are always exported with names in a mangled form that is specific to a particular version of the compiler.
Their dll is usable by msvc only in that form, and will probably not even work between different versions of msvc, as Microsoft have changed their mangling scheme before.
If you have any leverage, you need to get them to change their evil ways. Otherwise you will need to use MSVC to write a shim dll, that will import all the classes, and re-export them via c functions that return interfaces.
I’m almost certain that you can’t link C++ libraries across compilers like that. I’ve tried, really hard, but it was a long time ago and I don’t remember the details. i think for C libraries is possible, with a lot of hacks.
I just looked up with MinGW is on Wikipedia. According to that article, MinGW comes with redistributable import libraries.
Just thought I’d add my two cents here.
MinGW however uses the GCC name mangling scheme, that includes searching for external symbols, so it doesn’t recognize the MSVC mangled names. The linker could easily solve this by remangling the external symbols to match MSVC and then check again if there is a match. Maybe this will be implemented someday. I’ve solved this in my own programming language in a similar way but that of course includes my own linker.
Источник
