Re: MSW DLLs support in libtool

[Evgeny Grin]

-----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-----