Simon Richter <Simon.Richter <at> hogyros.de> writes: > 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 [...]
Yes, and this is fine. I'll obviously have shared libraries on the other systems, but why should I have them for Windows too when I don't need them there? > 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. Thanks, I know all this but it's not really relevant here anyhow. The fact is that linking non PIC into DLLs works perfectly fine under Windows, always did and always will. So it makes absolutely no sense whatsoever to check whether a library contains PIC or not when targeting Windows: you're checking for something that is completely irrelevant as everything is going to work no matter what the result of the check is. Except that it currently doesn't because the check fails and so the shared library is not being created. If this doesn't fit your definition of irony, I don't know what does. > So support for linking shared into static libraries is essentially > "win32 only", but creating a special mode for that would make no sense, Yes, we agree on this. Last thing we need is an additional mode in libtool. Instead libtool should just unconditionally skip the check for PIC when targeting Windows, it's as simple as that. What possible purpose could there be in checking something that we don't care about anyhow? > because then the source would no longer be portable and we wouldn't need > libtool. This is a complete non sequitur. My code is quite portable but it uses static Windows libraries and shared libraries under Unix. So what? > 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)? I'm building Boost static libraries manually myself because their abomination of bjam doesn't support cross-compiling to Windows correctly, at least in the ancient version of Boost I have to use, so they don't use decorated names. But this is again irrelevant, even if I can work around the problem somehow, this problem shouldn't exist in the first place. Several concrete questions in this thread asking for any benefits of the current libtool behaviour went unanswered, but let me try once again nevertheless: do you see any useful consequences of performing the check for PIC when targeting Windows in libtool? If you do, what are they exactly? And if you don't, why do you still think it should be done? Thanks in advance, VZ _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
