Hi, On 10.02.2016 17:49, Vadim Zeitlin wrote:
> *** Warning: Trying to link with static lib archive > /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have > *** because the file extensions .a of this argument makes me believe > *** that it is just a static archive that I should not use here. Linking a static library into a shared library will only ever work on Windows, and (with lots of warnings) Linux on 32-bit x86, because these two platforms are the only ones supporting run-time relocation of code that wasn't compiled to be position independent. On Windows, that is the default behaviour -- all PE binaries are completely relocatable, mostly because Windows 3.11 required that. On Linux for i386, the dynamic linker supports relocations outside the GOT and PIC, which creates unshareable pages and generally sucks, but was necessary to port some software back then. So support for linking shared into static libraries is essentially "win32 only", but creating a special mode for that would make no sense, because then the source would no longer be portable and we wouldn't need libtool. The extra hoops for creating Windows DLLs are due to additional constraints on the source code, but this would be relaxing a constraint that exists on all platforms but one. Libtool should in principle find the import library for the DLL and link against that. Boost is a little bit special because they encode the version number and several compiler options in the DLL name. Does it link correctly if you use the fully decorated name (because that is also what you'd use on Linux)? Simon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
