[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MSW DLLs support in libtool

From: Evgeny Grin
Subject: Re: MSW DLLs support in libtool
Date: Wed, 10 Feb 2016 22:30:18 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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

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

Version: GnuPG v2


reply via email to

[Prev in Thread] Current Thread [Next in Thread]