Re: -no-undefined on Win32
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
Re: -no-undefined on Win32
29.04.2014, 11:36, Peter Rosin p...@lysator.liu.se: 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. Correct. But this is another topic, which I raised already in this mailing list. 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? 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! So again we return to first question. What's advantage of requiring -no-undefined flag on win32? If code is designed well for win32 then compiler/linker can create shared lib. No advantage of using -no-undefined as lib will not use undefined symbols in any way. If code is not designed for win32 then compiler/linker will fail to create shared lib. No advantage of using -no-undefined. For linux systems I see advantages of -no-undefined: to force produced lib to have all symbols defined (or fail) and to check that all symbols are defined for lightweight emulation of win32 behavior. But for win32 -no-undefined flag must be used automatically as real checks for undefined symbols will be done by linker anyway. 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'm a volunteer. :) I'm not suggesting to delete or change -no-undefined flag. All projects that have this flag will continue to function as before. But new projects can skip unnecessary step, unless they want to have no undefined symbols on Linux/other platforms - in this case -no-undefined can be used as before. 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? Currently you have to properly write code AND specify -no-undefined for win32. So current behavior results in working library in less cases as specifying -no-undefined without correct code will not result in working library. Because it breaks projects depending on current behavior? I'm not suggesting to remove this option, so projects depending on current behavior will continue to work as before. Only will fail in less cases. :) Or are you mainly referring to your desire to link static libs into a shared lib? No, it was another topic that was already discussed. Thanks for constructive answers! -- Best Wishes, Evgeny Grin ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined on Win32
On 2014-04-29 17:30, Evgeny Grin wrote: 29.04.2014, 11:36, Peter Rosin: 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? 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! So again we return to first question. What's advantage of requiring -no-undefined flag on win32? If code is designed well for win32 then compiler/linker can create shared lib. No advantage of using -no-undefined as lib will not use undefined symbols in any way. If code is not designed for win32 then compiler/linker will fail to create shared lib. No advantage of using -no-undefined. You are too focused on shared libs, you cannot ignore static libs like that. You also cannot ignore Cygwin and AIX, which are Posixy enough to make the code designed for win32, or not distinction fall apart. The -no-undefined option is not specifically tied to win32, it is tied to all systems incapable of linking shared libraries with undefined symbols. For linux systems I see advantages of -no-undefined: to force produced lib to have all symbols defined (or fail) and to check that all symbols are defined for lightweight emulation of win32 behavior. But for win32 -no-undefined flag must be used automatically as real checks for undefined symbols will be done by linker anyway. Here you are making the (perhaps common?) mistake of mixing the ld flag --no-undefined (two dashes) with the Libtool flag -no-undefined (one dash). The ld flag is indeed documented to behave as you say, but the Libtool flag is not. Libtool -no-undefined will be ignored on most systems and will have effect only on systems which cannot link shared libraries at all with undefined symbols (such as win32, Cygwin and AIX). Passing -no-undefined to Libtool will not make Libtool pass --no-undefined to ld. 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'm a volunteer. :) I'm not suggesting to delete or change -no-undefined flag. All projects that have this flag will continue to function as before. But new projects can skip unnecessary step, unless they want to have no undefined symbols on Linux/other platforms - in this case -no-undefined can be used as before. You would break old projects that rely on a consciously left out -no-undefined flag, i.e. projects that have made the decision that a static lib is a perfectly fine outcome on some systems. Those projects would fail with your suggested changes when the shared library cannot be linked, because of unresolved symbols. 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? Currently you have to properly write code AND specify -no-undefined for win32. Again, -no-undefined is not tied to win32 specifically, it's also needed on some Posixy systems. So current behavior results in working library in less cases as specifying -no-undefined without correct code will not result in working library. Again, a static library is not an automatic fail. Because it breaks projects depending on current behavior? I'm not suggesting to remove this option, so projects depending on current behavior will continue to work as before. Only will fail in less cases. :) Not true, see above. Cheers, Peter ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined on Win32
20.04.2014, 05:15, Bob Friesenhahn bfrie...@simple.dallas.tx.us: On Fri, 18 Apr 2014, Evgeny Grin wrote: Libtool always defaults to successful compilation and link, to the maximum extent possible. That's nice, leave it to compiler and linker. If something can be compiled and linked, it will be compiled and linked. If it can't be, then compiler or linker will fail. Why giving up before even try? The GNU/Autoconf philosophy has always been that if software configures successfully that there should be a very high probability that the sofware will compile and work. Success at compiling on several platforms should indicate that it is highly likely to also compile on other platforms (including platforms that the package authors don't have access to). If the software fails to compile, or fails to work, there is substantial possibility that the user won't know how to solve the problem. Good. But requiring -no-undefined for Win32 flag lower probability of successful compile. It's absolutely normal that something can be compiled on one system and can't be on other system. According autoconf paradigm, code should be compiled if it use platform supported features. So configure checks host and target platforms, compiler, linker and other things and do dirty work to create correct configuration in makefiles, libtool, compiler wrapper etc. But if code designed to use some platform dependent features like epoll and epoll is not available on target platform then compile will fail. So let's add to libtool -disable-epoll flag and let libtool fail if target platform don't support epoll and this flag is not specified. It's far more logical to use flags like other GNU tools (GCC, binutils) use it. For example, this fictional flag -disable-epoll must prevent epoll usage on platforms that support epoll so code with epoll functions will fail to compile. On platforms without epoll support, code with epoll function will fail to comple in any case. Undefined symbols is just one of platform features. I can repeat again, let's simplify developer work instead of complicating. libtool must use -no-undefined for win32 targets automatically. Best Wishes, Evgeny ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined on Win32
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. 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. 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. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined on Win32
29.04.2014, 05:59, Bob Friesenhahn bfrie...@simple.dallas.tx.us: 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. 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. 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. :) 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? -- Best Wishes, Evgeny Grin ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined on Win32
On Fri, 18 Apr 2014, Evgeny Grin wrote: Libtool always defaults to successful compilation and link, to the maximum extent possible. That's nice, leave it to compiler and linker. If something can be compiled and linked, it will be compiled and linked. If it can't be, then compiler or linker will fail. Why giving up before even try? The GNU/Autoconf philosophy has always been that if software configures successfully that there should be a very high probability that the sofware will compile and work. Success at compiling on several platforms should indicate that it is highly likely to also compile on other platforms (including platforms that the package authors don't have access to). If the software fails to compile, or fails to work, there is substantial possibility that the user won't know how to solve the problem. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined on Win32
On Thu, 17 Apr 2014, Evgeny Grin wrote: Hi, It's strange for me that last line in following qoute from ltmain.in is commented out: --- # It is impossible to link a dll without this setting, and # we shouldn't force the makefile maintainer to figure out # what system we are compiling for in order to pass an extra # flag for every libtool invocation. # allow_undefined=no --- Almost all project ported to Win32 already have -no-undefined options, but this always add more headache on porting to Win32. If lib contains some undefined symbol, then dll will not be created regardless of using -no-undefined. If lib doesn't contain any undefined symbols, then dll can be created so why forcing use -no-undefined? Why does it create more headache when porting to Win32? Using this option indicates that the project has been constructed in a way which will work on systems which do not allow undefined symbols. Many projects (particularly those targeting only GNU/Linux because it is a popular operating system) are not suitably constructed and require adaptation. Libtool always defaults to successful compilation and link, to the maximum extent possible. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined on Win32
18.04.2014, 19:17, Bob Friesenhahn bfrie...@simple.dallas.tx.us: Why does it create more headache when porting to Win32? Using this option indicates that the project has been constructed in a way which will work on systems which do not allow undefined symbols. Many projects (particularly those targeting only GNU/Linux because it is a popular operating system) are not suitably constructed and require adaptation. As it's required mostly for Win32, project creators don't use this option by default. Moreover, to ensure maximum portability, this option often used conditionally for win32 only. I can't get the idea, why libtool needs information that author is aware of undefined symbols (or aware of something else). This is inconsistent with other GNU tools. For example, GCC don't need information that author is aware of C++11 features. You can instruct GCC to use C++11 dialect or instruct to use C++03 dialect (and not use C++11 features). I suggest to use the same logic for libtool. Use -no-undefined options to instruct linker to not use undefined symbols where it's possible to use undefined symbols. If some particular platform always need some compiler/linker option for shared lib then substitute required option automatically. The main idea of libtool (as I understand it) is simplification creation of static and shared lib, but currently this will make compilation more difficult than without libtool. Libtool always defaults to successful compilation and link, to the maximum extent possible. That's nice, leave it to compiler and linker. If something can be compiled and linked, it will be compiled and linked. If it can't be, then compiler or linker will fail. Why giving up before even try? -- Best Wishes, Evgeny Grin ___ https://lists.gnu.org/mailman/listinfo/libtool
