[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: Fri, 12 Feb 2016 20:08:05 +0300
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Hash: SHA256

On 12.02.2016 10:21, Peter Rosin wrote:
> On 2016-02-11 12:23, Evgeny Grin wrote:
>> On 11.02.2016 11:03, Peter Rosin wrote:
>>> Well said, I would also like to add that libtool -no-undefined *does* *not*
>>> imply ld --no-undefined. I.e. If you add libtool -no-undefined, then the
>>> *only* thing that changes is that libtool actually attempts the shared
>>> build.
>> Libtool must attempt to build shared version if configured with
>> "--enable-shared" and must not attempt to build it if configured with
>> "--disable-shared". It's up to linker to fail if shared build is not
>> possible. "Configure" job is to resolve everything that required.
>> On W32 this sounds like "-linker-will-not-fail". Why make any
>> predictions or assumptions if it possible to just try to link?
> Below I will discuss the case where no --{en,dis}able-{shared,static}
> options have been given to libtool.
> If you have not specified any of the --{enable,disable}-{shared,static}
> options and have a library that have not been declared with
> -no-undefined, libtool may fail on Windows (and AIX) if libtool should
> attempt a shared build. This is the reason why libtool does not even
> attempt it. 
But even with this option libtool may fail, right?
So this "-no-undefined" doesn't have real influence on failing. Failure
is depend only on compiler options.
Let's add option "--all-headers-are-present" and do not try
precompile/compile if this option is not specified. Because compiler may
fail if some headers are missing. So better no to try compilation.

Really, try and see the result!

> I'm not certain how it will go if --disable-static (or
> --enable-shared) has been specified w/o -no-undefined, but there are
> two options for libtool. 1) go ahead and try the shared build, or
> 2) fail without trying. I think 2) is what happens, but that there
> used to be a bug which made libtool do a static build anyway. You can
> argue that 1) should happen instead, but I see no reason not to add
> -no-undefined instead, so that libtool can safely build both static
> and shared when no specific --{enable,disable}-{shared,static} is given.
> That is simply much more consistent. I still hate that -no-undefined
> is not the default; it would have been much better to force the odd
> libraries that can't live with that option to declare the reverse
> situation. But alas, that ship has sailed.
I still don't see any real advantage of "-no-undefined". Currently you
must specify it so libtool will be sure, that linking will not fail. But
linking may fail even if this libtool option is specified.

Just remove requirement for in on W32 and AIX. Even libtool reports
"Since this library must not contain undefined symbols, because either
the platform does not support them or it was explicitly requested with
- -no-undefined, libtool will only create a static version of it."
Why duplicate requirement for platform if libtool already know it.

>>> Conditionally adding -no-undefined for systems where it matters is overly
>>> defensive.
>> Not agree.
>> Let's consider that some dev is working on porting some lib to W32 (or
>> AIX). Lib is already ported to
>> Linux/Darwin/FreeBSD/OpenBSD/NetBSD/Solaris/HP-UX. And usually some
>> ports contain OS-specific code parts. This developer need to add
>> "-no-undefined" flag for new port. There are two choices: add flag
>> unconditionally and test lib under all OSes (better - with all possible
>> options and on different OS versions) or just conditionally add flag for
>> specific OS. I bet which way will be chosen.
> I still maintain that it is overly defensive, and that the defensive
> behavior is explained by the fact that the libtool -no-undefined flag
> is mixed up with ld --no-undefined. Do you understand that the libtool
> flag is a NOP for all of the preexisting ports in your example?
No, it's still not obvious for me that this flag is NOP for all those
platforms. And I'm sure that it's not obvious not only for me. I didn't
see any documentation that clearly state that libtool "-no-undefined"
option is NOP for anything except W32 and AIX.
Moreover, if it does matter only for W32 and AIX, let's rename it to
"-w32-aix-shared-compatible". And add more flags, like
"-linux-compatible", "-open-bsd-compatible". This will signal libtool
that developed checked compatibility of build system with specific OS.
And do not try to link if flag not specified as link may fail. Later
let's add "-arm-compatible", "-mips-compatible", "-xx64-compatible" and
do not try to compile as compile may fail. Instead of it always
transparently fallback to x86 compilation as it may be useful. Good idea?

Actually, quoted message from libtool produce feeling that
"-no-undefined" will force libtool to link with "--no-undefined" even on
platforms that support undefined symbols. Is it wrong? Or libtool
message is incorrect?

>> Repeat once more: with OS-specific code parts you can't add
>> "-no-undefined" unconditionally.
> Are you sure? The flag will only make a difference on Windows and AIX,
> which is not totally out of the question to actually verify. It think
> it would be a rare case indeed if it would not be ok to add it
> unconditionally (if it is correct to add it at all), and I'd actually
> be surprised if you could dig up /any/ such case at all (in a real
> package, that is). I.e. where -no-undefined is correct for Windows but
> not AIX (or vise versa).
Seems that libtool message is incorrect, but "-no-undefined" is usually
added after reading this message.

Anyway, what's drawback of assuming "-no-undefined" on W32 and AIX (or
on all platforms)?

- -- 
Best Wishes,
Evgeny Grin
Version: GnuPG v2


reply via email to

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