Re: MSW DLLs support in libtool

[Vadim Zeitlin]

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