On Wed, 10 Feb 2016 10:02:25 +0100 Peter Rosin <p...@lysator.liu.se> 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
pgpQ9O3wqaHMK.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool