On 2014-04-29 07:25, Evgeny Grin wrote: > 29.04.2014, 05:59, "Bob Friesenhahn": >> On Mon, 28 Apr 2014, Evgeny Grin wrote: >>> Good. But requiring "-no-undefined" for Win32 flag lower probability of >>> successful compile. >> In what way does it lower the probability of a successful compile? >> Static linkage is much more portable than dynamic. > That was another asked question: why libtool didn't fail if requested dynamic > lib was not build. > Anyway, if I'm building dynamic lib and it was not built, that's called > "unsuccessful build".
Here you have a point, methinks. If you have specified -disable-static, it is surprising that static can be the only output, instead of a fail. >> The situation you outlined is due to a defective package >> preparation/build environment. A proper build has just one version of >> a given library in a link. > Could you explain this a little bit? > In the topic "-no-undefined on Win32" I was talking about only one version of > lib. It is defective since the project has failed to specify -no-undefined when it proceeds with a link without undefined symbols. Just add the dang flag and be done with. Yes, I did read the argument that some projects decide to special-case adding -no-undefined only for systems that must have it to produce shared libs, or refuses to add it outright, but that's just plain silly. If someone doesn't want to support weird systems/tools, why not use $CC -shared directly and erase Libtool from the project instead? Seriously! >> Regardless, it is very unlikely that libtool will react to your plea >> (if it does at all) in a timely fashion and so you are best advised to >> fix your build without relying on significant changes in libtool. > All my builds were "fixed" already. > I'd like to improve libtool. > If *uncommenting* one line and deleting other line in libtool are significant > changes, then I'd like to significantly change libtool. :) You have "forgotten" the needed testsuite changes involved which should verify the new behavior. Those would probably be more significant than a couple of one-liners. You're also ignoring the impact on projects relying on the current behavior, how do you propose to handle them? A new flag? Named what? -undefined? -no-no-undefined? -has-undefined? -undefined-symbols? I suppose -disable-shared would do it, but that would *require* projects (or users) to special-case systems that now only require -no-undefined (which does nothing on "normal" systems), and that cannot be an improvement. > Could you answer my main question: why libtool don't follow logic of other > GNU tools? Instead of acting as a "tool" and passing required flags to > compiler/linker, libtool is acting as mentor and does not do it work until > you signal that you aware of something? Because the current behavior results in a working library in more cases? Because it breaks projects depending on current behavior? Or are you mainly referring to your desire to link static libs into a shared lib? In that case, perhaps because such usage is error-prone on most systems, and that the check is in place for all systems in the name of not complicating the Libtool code even further with even more special- casing for a seemingly questionable scenario? Cheers, Peter _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
