Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Wed, 10 Feb 2016 10:02:25 +0100 Peter Rosin <address@hidden> wrote:

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

 Hello,

 But is this really different? The linker option can also be seen as such
declaration by the library author because if it is not the case, the build
would fail. And this is exactly why MSW linkers have no such options: this
declaration is never needed because it is implicit there.

PR> As for your point about non-trivial programs not working without
PR> special treatment, there are a large body of packages that build just
PR> fine using Cygwin on-top of Windows, without much in the way of special
PR> treatment.

 OK, maybe I underestimated the amount of Unix programs which don't do
anything Unix-specific. But they wouldn't be affected by any changes under
discussion unless they use disable-static, which they hopefully don't.

PR> I agree wholeheartedly with the notion that --disable-static should end
PR> up in a failure and not somehow degrade to a static build anyway. I
PR> also recognize your frustration.

 Thanks, I do appreciate it!

PR> Changing stuff in Libtool to help this situation is therefore extremely
PR> delicate, you risk breaking fragile workarounds that are rarely tested,
PR> if ever. If you change things, you should be quite sure that it does
PR> not cause regressions.

 Well, I think it won't. I could be wrong, of course, but this is one of
the reasons why I tried to explain my reasoning in details in
http://lists.gnu.org/archive/html/libtool/2016-02/msg00015.html
and I hope that if there is any problem with it, someone can point it out.

PR> Another angle on this topic is that I believe that the win32 LT_INIT
PR> option was added to not inflate configure overhead for packages not
PR> supporting Windows (i.e. conforming to your mindset that packages
PR> don't work w/o special treatment anyway). This is still a factor.
PR> Systems like buildroot and gentoo, where packages are built over and
PR> over, do not like if when configure times grow. Making the win32 option
PR> the default would perhaps regress their build times? I think this
PR> point is moot, because I think the overhead of the win32 LT_INIT option
PR> is quite insignificant,

 I agree.

PR> but I don't know that. Maybe it drags in some extra file or something?

 I don't think so, I don't see any difference with and without this option.

PR> Extra files could be an eye-sore to some
PR> puritan. Personally, I don't get why the win32 option exist at all.
PR> I see no reason to discriminate against Windows like that. Make the
PR> no-windows-purists opt out with no-win32 (or whatever) instead.

 I couldn't agree more.

 Regards,
VZ

pgppzTVjy0ks5.pgp
Description: PGP signature