Re: MSW DLLs support in libtool

[Peter Rosin]

Hi!

[Replying to various things across the thread]

On 2016-02-10 04:53, Vadim Zeitlin wrote:
> On Tue, 9 Feb 2016 21:29:23 -0600 (CST) Bob Friesenhahn <address@hidden> 
> wrote:
> 
> BF> On Wed, 10 Feb 2016, Vadim Zeitlin wrote:
> BF> >
> BF> > Sorry but this is just not true for the MSW DLLs. If the libtool user
> BF> > tries to build a DLL, you can safely assume that it will not have 
> undefined
> BF> > symbols. Anything else just doesn't make sense because it would always
> BF> > result in an error. Again, this is different from the traditional Unix
> BF> > shared libraries.
> BF> 
> BF> Why do you say this?  Most software built using libtool still comes 
> BF> from Unix type systems.
> 
>  And almost all of it wouldn't compile under MSW. I think it's reasonable
> to assume that if an effort was made to port some piece of software to MSW,
> it wouldn't have any undefined symbols in its DLLs.
> 
>  Of course, if you really want to just compile it and don't care whether
> you get static or shared libraries, nothing prevents you from using
> --disable-shared and building static libraries only. Contrast this with the
> current situation when using --disable-static doesn't change anything at
> all and static libraries are still being produced by libtool.
> 
> BF> Without the existing behavior it would be difficult to take a program
> BF> developed on a Unix type system and just compile it under Windows.
> 
>  In practice this is never going to work for any non-trivial program.

You appear confused (as almost everybody else) about what -no-undefined
means to libtool. The confusion stems from(?) the similarly named linker
option, --no-undefined, which apparently does what people expect from
the libtool -no-undefined option. Alas, the fact is that libtool
-no-undefined is not a request to complain if there are undefined
symbols (which, as you say, happens automatically on Windows), it is a
declaration by the library author that there are in fact no undefined
symbols in the library. The situation is unfortunate, and I also hate
the bad libtool default.

As for your point about non-trivial programs not working without
special treatment, there are a large body of packages that build just
fine using Cygwin on-top of Windows, without much in the way of special
treatment. Cygwin also suffers the from the cursed -no-undefined mess,
since the underlying system is Windows and DLLs cannot have undefined
symbols. My point here is that are a non-trivial amount of packages that
indeed builds fine on Cygwin where the only "porting effort" is that
silly -no-undefined option. So, your "is never going to work" is simply
not true, all the linking limitations mentioned by Bob applies equally
to Cygwin and native Windows, but compiling is so much easier given
the Cygwin POSIX support, which of course is lacking on native Windows.

I agree wholeheartedly with the notion that --disable-static should end
up in a failure and not somehow degrade to a static build anyway. I
also recognize your frustration. However, one important thing to consider
when it comes to Windows support is that many many package maintainers
are sorely tired of all the special casing, do not bother getting a
working build setup, etc etc etc. Windows support is sketchy in a lot of
places. Changing stuff in Libtool to help this situation is therefore
extremely delicate, you risk breaking fragile workarounds that are
rarely tested, if ever. If you change things, you should be quite sure
that it does not cause regressions.

Another angle on this topic is that I believe that the win32 LT_INIT
option was added to not inflate configure overhead for packages not
supporting Windows (i.e. conforming to your mindset that packages
don't work w/o special treatment anyway). This is still a factor.
Systems like buildroot and gentoo, where packages are built over and
over, do not like if when configure times grow. Making the win32 option
the default would perhaps regress their build times? I think this
point is moot, because I think the overhead of the win32 LT_INIT option
is quite insignificant, but I don't know that. Maybe it drags in some
extra file or something? Extra files could be an eye-sore to some
puritan. Personally, I don't get why the win32 option exist at all.
I see no reason to discriminate against Windows like that. Make the
no-windows-purists opt out with no-win32 (or whatever) instead.

> BF> It is thought that errors are bad and successful compilation is good.
> 
>  I completely and utterly disagree with this. Silently doing the wrong
> thing is by far a worse thing to do than giving a clear error indicating
> what needs to be done to correct it. Especially if there is no way to
> override this "smart" behaviour.
> 
>  To be blunt, libtool support for MSW looks like a hack. It has no real
> logic and just blindly tries to do everything to produce something,
> whatever it is. It might indeed be sufficient if you're just compiling
> "Hello world" for MSW and are happy to get whatever you get with the
> minimal amount of effort, but it's just not good enough for any real
> software where you really do want to get your 10MB DLL and 3 1MB
> applications using it instead of getting 3 10MB applications, for example.

I agree with the sentiment of your complaints, but there are details to
consider. As always.

Cheers,
Peter