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 > <bfrie...@simple.dallas.tx.us> 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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
