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