On 2016-02-11 12:23, Evgeny Grin wrote: > On 11.02.2016 11:03, Peter Rosin wrote: >> Well said, I would also like to add that libtool -no-undefined *does* *not* >> imply ld --no-undefined. I.e. If you add libtool -no-undefined, then the >> *only* thing that changes is that libtool actually attempts the shared >> build. > Libtool must attempt to build shared version if configured with > "--enable-shared" and must not attempt to build it if configured with > "--disable-shared". It's up to linker to fail if shared build is not > possible. "Configure" job is to resolve everything that required. > On W32 this sounds like "-linker-will-not-fail". Why make any > predictions or assumptions if it possible to just try to link?
Below I will discuss the case where no --{en,dis}able-{shared,static} options have been given to libtool. If you have not specified any of the --{enable,disable}-{shared,static} options and have a library that have not been declared with -no-undefined, libtool may fail on Windows (and AIX) if libtool should attempt a shared build. This is the reason why libtool does not even attempt it. I'm not certain how it will go if --disable-static (or --enable-shared) has been specified w/o -no-undefined, but there are two options for libtool. 1) go ahead and try the shared build, or 2) fail without trying. I think 2) is what happens, but that there used to be a bug which made libtool do a static build anyway. You can argue that 1) should happen instead, but I see no reason not to add -no-undefined instead, so that libtool can safely build both static and shared when no specific --{enable,disable}-{shared,static} is given. That is simply much more consistent. I still hate that -no-undefined is not the default; it would have been much better to force the odd libraries that can't live with that option to declare the reverse situation. But alas, that ship has sailed. Maybe, we should add a new flag -have-undefined (or something) that these oddball libs can start using, in order to eventually phase out -no-undefined? >> Conditionally adding -no-undefined for systems where it matters is overly >> defensive. > Not agree. > Let's consider that some dev is working on porting some lib to W32 (or > AIX). Lib is already ported to > Linux/Darwin/FreeBSD/OpenBSD/NetBSD/Solaris/HP-UX. And usually some > ports contain OS-specific code parts. This developer need to add > "-no-undefined" flag for new port. There are two choices: add flag > unconditionally and test lib under all OSes (better - with all possible > options and on different OS versions) or just conditionally add flag for > specific OS. I bet which way will be chosen. I still maintain that it is overly defensive, and that the defensive behavior is explained by the fact that the libtool -no-undefined flag is mixed up with ld --no-undefined. Do you understand that the libtool flag is a NOP for all of the preexisting ports in your example? So, even if you actually tried to make a convoluted example which would break if -no-undefined was added unconditionally by a new port, you failed. > Repeat once more: with OS-specific code parts you can't add > "-no-undefined" unconditionally. Are you sure? The flag will only make a difference on Windows and AIX, which is not totally out of the question to actually verify. It think it would be a rare case indeed if it would not be ok to add it unconditionally (if it is correct to add it at all), and I'd actually be surprised if you could dig up /any/ such case at all (in a real package, that is). I.e. where -no-undefined is correct for Windows but not AIX (or vise versa). Cheers, Peter _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool