Re: MSW DLLs support in libtool

[Peter Rosin]

On 2016-02-11 00:38, Bob Friesenhahn wrote:
> On Wed, 10 Feb 2016, Evgeny Grin wrote:
>>
>> 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
> 
> The "-no-undefined" option is not actually Win32 specific.  IBM's AIX has
> build configurations which benefit from it.
> 
> Also, "-no-undefined" does not indicate if the library has undefined
> symbols (many DLLs have undefined symbols).  It indicates that the build
> configuration has agreed to supply any additional dependency libraries
> if there otherwise would be undefined symbols.

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. How the shared build is performed is not changed in any way, so
if there actually are undefined symbols (not supplied by the build etc etc)
and the platform can handle that, then that will continue to work.
Conditionally adding -no-undefined for systems where it matters is overly
defensive.

Repeat after me:

libtool -no-undefined is not at all the same thing as ld --no-undefined.

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Peter Rosin]

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

Maybe, we should add a new flag -have-undefined (or something) that
these oddball libs can start using, in order to eventually phase out
-no-undefined?

>> 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? So,
even if you actually tried to make a convoluted example which would
break if -no-undefined was added unconditionally by a new port, you
failed.

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

Cheers,
Peter

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



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?

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

Repeat once more: with OS-specific code parts you can't add
"-no-undefined" unconditionally.

- -- 
Best Wishes,
Evgeny Grin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWvG9HAAoJEL96xKXqwrr0awwH/3HLwxmFdtCm9OuiJbq2hicS
7OalbEbCAuB3hYiey9zNXAHeGw00/vioNjWIfkb/urMbybXVQ1u1ZyGsvrj5fw+O
5G0wbhdYAg+ZSShy+Glzzp2701FZBIlS7OkKIKI8CCP20UyJ0NRO9NHWEFkFl+0M
86Gc8QbTr5v+8CuSQCog3BPK5k96QujJHBbwBbcmwaZQFODlL7VnfP3XGPb3AJYl
5tU63xyYOEj3ODrlF4cu3s6I2fdQY9SYnzOREJ9irsqODoztWWOMjdlQW/sVml3Q
QjnPvaBqhfjFsh0m9BeMSsPs/KXk3LmeZlH5TlNmcsrjgRuylsfxX+bAqSWv+jM=
=oF06
-END PGP SIGNATURE-

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Bob Friesenhahn]

On Thu, 11 Feb 2016, Evgeny Grin wrote:


Repeat once more: with OS-specific code parts you can't add
"-no-undefined" unconditionally.


GraphicsMagick (which compiles on a wide variety of systems, including 
Windows and AIX) has been specifying -no-undefined as a standard 
option (used on any OS) in its makefiles for as long as I can 
remember.


No harm was encountered due to this.

This discussion is feeling rather Shakespearian.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10.02.2016 18:51, Nick Bowler wrote:
> The default (on all platforms) is to create both static libraries and,
> when possible, shared libraries.
This statement is ether not correct or incorrectly documented.
Currently "configure --help" show those lib options by default:
  --enable-shared[=PKGS]  build shared libraries [default=yes]
  --enable-static[=PKGS]  build static libraries [default=yes]

There is not "=auto" option for shared or static versions. Only "yes" or
"no".
So, it's explicitly specified whether static will be created and whether
shared will be created. So "make" must ether create requested versions
or fail.

- -- 
Best Wishes,
Evgeny Grin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWvGTDAAoJEL96xKXqwrr0s3UIAJgg0PxO8F7UteHiS35GXXU+
bzZklmHxfPovFG/yZPPlwFOdnlb8zrNKKuYR2PhUSs3QYZV57W9iO/pnigMoLSGq
tau00pBIxNHJLh3K4XaTL1XtBawIeQAqQNeYGoOepovth5x+qYqHun4wijonLBRz
zl1kO/BxUhJ7L2yP9yylKamlbd6e05DH756UU4nyQ7voqjykQcaKaPam88wlC2O4
fnz6Hw058t7O6K/k3QwHz/755qOniS7VBcLGgf2YNiisSC0K3PK67serUe639ay/
rDUNm7Nazal1duGgODdIzDJ5A4Ol1GjFh8uvYYDK2Xzj9yt7tugy27gB10KtUqY=
=/aBD
-END PGP SIGNATURE-

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Bob Friesenhahn]

On Thu, 11 Feb 2016, Evgeny Grin wrote:


On 10.02.2016 18:51, Nick Bowler wrote:

The default (on all platforms) is to create both static libraries and,
when possible, shared libraries.

This statement is ether not correct or incorrectly documented.
Currently "configure --help" show those lib options by default:
 --enable-shared[=PKGS]  build shared libraries [default=yes]
 --enable-static[=PKGS]  build static libraries [default=yes]

There is not "=auto" option for shared or static versions. Only "yes" or
"no".
So, it's explicitly specified whether static will be created and whether
shared will be created. So "make" must ether create requested versions
or fail.


These are 'enable' options.  Use of 'enable' implies "best effort".

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Nick Bowler]

On 2/11/16, Evgeny Grin  wrote:
> * change default shared lib mode from "on" to "auto" or "try" and fail
> if shared lib cannot be created when mode is "on". With that logic
> "make" will do what requested instead of guessing that "something may be
> useful even if not requested". Alternatively - introduce new LT_INIT()
> flag "no-fallback-to-static".

This option already exists.  It is called "disable-static".

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 11.02.2016 17:42, Bob Friesenhahn wrote:
> GraphicsMagick (which compiles on a wide variety of systems, including
> Windows and AIX) has been specifying -no-undefined as a standard option
> (used on any OS) in its makefiles for as long as I can remember.
> 
> No harm was encountered due to this.
Once I saw one men crossed busy 8 lanes high-speed highway by his foot.
He did it quite well without any harm.

> This discussion is feeling rather Shakespearian.
To summarize, I'd like to provide patches for:
* change default shared lib mode from "on" to "auto" or "try" and fail
if shared lib cannot be created when mode is "on". With that logic
"make" will do what requested instead of guessing that "something may be
useful even if not requested". Alternatively - introduce new LT_INIT()
flag "no-fallback-to-static".
* do not assume that "link MAY fail so I'll not try to link". Instead
try to link even if "-no-undefined" was not specified even on W32 and
see real result.
Is it OK?

- -- 
Best Wishes,
Evgeny Grin
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWvPcYAAoJEL96xKXqwrr0jREH/iWZcscGY6pvULGKZF7iCpa6
7xcPoZL8Fr6ubA+yog2RSGTAuhAD2TvH1uNJtDwG0desEV+AWhAqMiWG5YsXIR2k
V0O/i/R38iAiBfPjgTkvgT7Px5wdrJ5Wcxod/h8L45Md1G+CW0hY0HK8ni8mxREC
Rp+HMTq4gJSZYob7+IiMevwcFjP8pBqvjpzeS0fYtl7/NUBA8f6/nLpc7G3uTBuy
wpX558FwFvvsLwJs4qr2suzWmrixKYYJlee7Vxeo05GLmkBOaTx5E7Cw+23UiwEq
f4YmIqeoqdZc0MF+sa0az3azmSPH0gfksU1+05zlkV5XrrOqQUJ0nRbMfaCEEws=
=w5H4
-END PGP SIGNATURE-

___
https://lists.gnu.org/mailman/listinfo/libtool