-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 10.02.2016 6:18, Bob Friesenhahn wrote: > On Tue, 9 Feb 2016, Vadim Zeitlin wrote: >> >> 2. Enabling this option is not enough as you must also painstakingly add >> -no-undefined to all LDFLAGS. Why does libtool need to force you to do >> it instead of just using it unconditionally for all MSW DLLs knowing >> that they can *never* have any undefined symbols? While using this >> option is a good idea for the other platforms too anyhow, there just >> doesn't seem to be any reason to not use it implicitly for MSW, is >> there? > This is an indication that appropriate steps have been taken to apply > all needed dependencies at link time. This is often not the case. > Systems like GNU/Linux support implicit dependencies and so sometimes an > effort is made to not include dependencies, or they may be missed by > accident. Not really. Many libs, ported to W32, have special parts with W32 only and exclude other parts with non-W32 codes. Moreover, many libs have special Linux-only, Darwin-only, FreeBSD-only and other OSes exclusive parts. So if libs have no undefined symbols on some OS, it doesn't mean that libs will not have undefined symbols on other OS. And vice versa. Let's look on common path of developing some new library. At first step lib is written and tested on single OS (main OS on developer's machine, Ubuntu for example). Than OS support extended for other Linux distributions (unlikely, but some modifications may be required). After that, FreeBSD/Darwin support can be added. If lib uses, for example, some sockets functions, this most probably require additional coding. At some moment, someone may decide to port lib to W32. Up to this moment "-no-undefined" flag was not required and not used. To make sure that porting will not break other OSes, porting coder will add "-no-undefined" conditionally only on W32. Moreover, it's not possible to test all platforms variation so no reason to add "-no-undefined" unconditionally (keep in mind OS-specific code parts). As result - "-no-undefined" is used only on W32 without any practical benefit: if lib have some undefined symbols, it will not be build on W32 as shared lib regardless of "-no-undefined" flag. And conditionally used "-no-undefined" will not help to detect undefined symbols when developing on other platforms. And don't forget about OS-specific code parts! >> The most aggravating thing is that libtool really seems to go out of its >> way to make MSW DLLs creation more difficult than it needs to be with all >> the tests for things that can never happen. I realize that DLLs are very >> different from the typical Unix shared libraries which are libtool's >> bread >> and butter, but surely they're important enough in practice to have some >> special handling for them? > There is special handling. You already reported the -no-undefined > special handling. :-) Libtool was designed to make developing of libs simpler. Why adding complexity on this "-no-undefined"? >> If libtool has a goal of providing decent support for MSW DLLs, I could >> try submitting patches changing the things above to work in a more >> user-friendly way, but I'd really like to know if they would be welcome >> first or if, perhaps, the way things [don't] work now is a subtle hint >> that >> libtool just shouldn't be used if first-tier MSW support is required. > > It is important that change for Windows do not break the many other > supported platforms. Your changes are welcome if they assure this and > improve reliability and usability. > > There is a long-standing principle in the history of libtool that it > should provide consistent functionality across platforms and not do > things which encourage usages in one dominant platform which do not work > on the others. Will patch for libtool for automatically enabling "-no-undefined" for W32 shared lib be accepted? It will not break anything at all. - -- Best Wishes, Evgeny Grin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWu4Y5AAoJEN665qOCrkO/p8wP/0c0daigKlTKLz/HHnGLQl7W RQ3hvHY39GQIEZDvwG6TxC3fRlwQAi/Jnp7Bmr4gxLpwqOadnykj8Lv/iKjvWnnr ohCiBygYP85W0Mfb7lhqGny3HllN2sarya71WvGbBmKYDrrda54wZH0ZzgfCIESz A0ST2RCfTkbk8c3D3lo/TJRwLQshguCtvi8ko107iLzEd1GXxRSv0PNfwsAyaT3O 4zTdDSaPKI+exy63AXhLyes8Nydgq59ezzP35SRfuBMNf6CGIaFA2VCbG7bvhyaU 6m4F+Vzu7OeCXoHBIvxGIVdxJaUUrFvHopjV9n1W0EABaljP1iKorR/DaegERIi6 KKAFutiTPFQ9WWZSgUugOMAERzlu0x3zmlv3xvpbvH/gf82rgY4BTLA3Ap8eaDrH dqR6eTQt0qwiHixAx+0tZph+B8SuY/2cZRdxH97I9lx3k4CdOQk5TMFrEzAqD3k+ cjXS9LaEGpMWrS1rmqOnnl1mP+NYcQYF8Q5iBiHImwtzmUqj6s9FhV84IZnGuFFZ kSzApuEow3o1HEM64DUd7CMDkqUZbsKK/424WMVnCUIJ2SRRlPvkLm4/YL6KF2XM toe3Qq7NWU+qdFtvoPbWVXzXX3l/gx/XryUvqiPdNWUyaJNRLXsUhbDtQzJ5BIKs bj66gbebBWNPwOzP6HsQ =z76t -----END PGP SIGNATURE----- _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool