Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12.02.2016 23:23, Bob Friesenhahn wrote:
> On Fri, 12 Feb 2016, Evgeny Grin wrote:
> 
>> 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.
> 
> We don't do this sort of thing since we have no control over the future
> and don't know what the future will bring.  So we use generic options. 
> If we try to guess what the future may bring then we may guess wrong and
> someone will take us to task about our bad decisions.
It's not a future. It's present time. Currently "-no-undefined" means
"-w32-shared-compatible" or "-w32-aix-shared-compatible" (you know
better, but I can't find information about it in documentation. Not for
AIX, not for Windows)
We have a number of OSes. Let's add "-bsd-shared-compatible" and
"-darwin-shared-compatible" (plus some more). This will improve
compilation success as with those flags libtool will know that build
system is compatible with specific OS.
Does it correspond current libtool logic?

>> Anyway, what's drawback of assuming "-no-undefined" on W32 and AIX (or
>> on all platforms)?
> 
> As previously explained, it is more likely to lead to compilation
> success for packages which have not been crafted/tuned to succeed on
> targets where -no-undefined makes a difference.
Actually not. If static is disabled, build without "-no-undefined" must
be failed on W32, but can be succeed if tried. Does it improve something?
Even with enabled static, why not to try linking? Libtool can build
static upon result of linker. This will significantly improve number of
successful builds.

> A core Autotools principle is that the person compiling the software
> should be in control as much as possible.  This includes people who just
> received a tarball and are not the developer of the software. Another
> core principle is that defaulting to imperfect success is better than
> utter failure.
Than libtool failed at lest in two important points:
* You can't prevent fallback to static.
* You can't be sure that build result in what requested even if build
succeed.
No control at all for those.

Libtool is the only exception in GNU toolchain, including GCC, binutils
and autotools where "enable" means "may be". Could you name at least one
option (preferable important) in other tools where "enable" means "may be"?

Instead of hiding failures (which are totally *unobvious* even for
developers) is much better to fail with message like
'*** Linking shared lib failed. Try configure with options
"--disable-shared --enable-static".'
This will help much more!
It's very common that "make" output is dozen of tens screens and libtool
message is somewhere in the middle. It's really hard to understand
what's wrong, especially if you don't know what you need to find in this
text.

And using "-no-undefined" in LDFLAGS is not continent at all. You should
add it in the end of configure or any other link/run test will fail.

One more question. If compatibility with Win32 DLL is already signalled
by LT_INIT([win32-dll]) why is required to signal it again by
"-no-undefined"?

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

iQEcBAEBCAAGBQJWv25xAAoJEL96xKXqwrr0ieIIAKuI6n8AcdYKtdsGoNKAaWIh
KXLLYw/ZDquEqcS6RkVxG/dgFGDzMa8UkPPqpEhyN55qPsldJfd5BfcoE5056eeL
sTMvmJpqpBi5O03y2Bx5i2hNYkpusXyylJKaxwxMDF7ZcnOuR+Sr0nOokdXo6VQa
ZnTp0h3zTsmtX4JT7NpX20vYC7Y+tpHsj+ylNmVYYMu+76QfVeMC07Kt6QRLpOD2
JJ0GbvB96G+DW0IN2T4wAClFjChLjst6IINSSG/ZojJ1lmp5yxnPlWcGy2nqyMvU
3rIiJeHlq/sljBiMSu5lLpUVTLGxAylBjy9zzCMQDpa85XByBfg//QgSt+uAJnI=
=v4+N
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 13.02.2016 4:56, Vadim Zeitlin wrote:
>  Thanks, it's an interesting case and I didn't think about it. However
> while it's true that bad things can/will happen in this case, wouldn't they
> also happen if two DLLs link with the different versions of the same DLL?
> It's not totally clear how would you set things up to make the build pick
> two different versions of a static library, but  presumably the same could
> be done for the import libraries too. Of course, only one DLL would be
> effectively loaded into the process address space (unless you have two
> import libraries with the same name corresponding to the DLLs with
> different names, and if we're considering really perverse cases, why not?),
> but one or the other DLL linking with it will crash if the two versions are
> not ABI-compatible.
Yes, this is the real problem. Kodi for Windows uses a lot of DLLs. Some
of sources of those DLLs a little outdated and require specific other
libs. Mostly used libs are zlib, libiconv and openssl. We have to use
all those libs as DLLs, but they are not always ABI compatible. So it's
a process of try-and-fail when combining all DLLs into working set. Life
will be much simpler if many of those libs will be statically linked
into DLLs.

> PR> If libtool should be in the business of protecting from such disasters
> PR> is another matter...
> 
>  I don't think it should and I don't think it can. And I'm also pretty sure
> that the current protection against this is, first, unintentional (because
> there are surely more direct ways to check for this) and, second, if we
> accept that forbidding linking with static libraries completely is worth
> this protection in Windows DLL case, then it logically follows that we
> should just never link with static libraries at all. And this is (luckily,
> I don't want to give anybody any ideas...) not what libtool does.
> 
>  So I still think that the check for PIC dependencies under Windows is
> useful. Do you, or anybody else, believe it is and can anybody think of any
> practical example when it would be useful?
I think it's time for sending patches. With keeping in mind backward
compatibility.

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

iQEcBAEBCAAGBQJWv3SzAAoJEL96xKXqwrr0c5YH/jjpJBLXHjCV7VBpvXpTe8zi
AdMUHMibsdNEEvLq5IepWcMNCuC+h4efPQe7DcE6O7GKauCwqsoWhf+YUyfTJLV9
zLV6kv76q3lQIfsZYGJUq07iCYMdBSlSemZEAcrArFWNnMnutTUv1v8URKNlWuzy
AfueMVjYty2s3S3cg3boAOjDcqKjw132iljXxPTrkC8SHoEsGlSqHJJbWQ1ecjZJ
05q0IHn+SM2l5mI8fRRIqsHznq4PIZ5Vq9jHU5iTk7Zq1PTha/6IWoXjHt7TEqv5
ntG+OBJ5UPMU+7KdhNlTCEIeF+O/fuziqCf5+CflH3weY+512kE4BaPTjBTfG3E=
=2upu
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12.02.2016 0:14, Nick Bowler wrote:
> 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".

Actually, no. See:

$ libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996

Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ../configure --disable-static
checking for a BSD-compatible install... /usr/bin/install -c


checking whether build environment is sane... yes
{skip}
checking whether to build shared libraries... yes


checking whether to build static libraries... no
{skip}

$ make LIBS=-ltdbcstub103
{skip}
/bin/sh ../../libtool  --tag=CC   --mode=link gcc -fvisibility=hidden
- -I/mingw64/include -IT:/msys64/mingw64/include
- -IT:/msys64/mingw64/include/p11-kit-1 -IT:/msys64/mingw64/include -g -O2
- -fno-strict-aliasing -LT:/msys64/mingw64/lib -lgnutls -export-dynamic
- -no-undefined -Wl,--output-def,.libs/libmicrohttpd.def -X CClinker
- -static-libgcc -version-info 48:0:36  -o libmicrohttpd.la -rpath
/usr/local/lib libmicrohttpd_la-connection.lo
libmicrohttpd_la-reason_phrase.lo libmicrohttpd_la-daemon.lo
libmicrohttpd_la-internal.lo libmicrohttpd_la-memorypool.lo
libmicrohttpd_la-mhd_mono_clock.lo libmicrohttpd_la-sysfdsetsize.lo
libmicrohttpd_la-mhd_str.lo libmicrohttpd_la-response.lo
libmicrohttpd_la-postprocessor.lo libmicrohttpd_la-digestauth.lo
libmicrohttpd_la-md5.lo libmicrohttpd_la-basicauth.lo
libmicrohttpd_la-base64.lo libmicrohttpd_la-connection_https.lo
../../src/platform/libplatform_interface.la -LT:/msys64/mingw64/lib
- -lgnutls -L/mingw64/lib -lgcrypt -lgpg-error
libmicrohttpd_la-microhttpd_dll_res.lo -ltdbcstub103

libtool: link: rm -fr  .libs/libmicrohttpd.a .libs/libmicrohttpd.la
.libs/libmicrohttpd.lai




*** Warning: linker path does not have real file for library
- -ltdbcstub103.

*** I have the capability to make that library automatically link in
when

*** you link to this library.  But I can only do this if you have a


*** shared version of the library, which you do not appear to have


*** because I did check the linker path looking for a file starting


*** with libtdbcstub103 and none of the candidates passed a file format
test

*** using a file magic. Last file checked:
T:/msys64/mingw64/lib/libgpg-error.dll.a

*** The inter-library dependencies that have been dropped here will be


*** automatically added whenever a program is linked with this library


*** or is declared to -dlopen it.





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


Even after this bug will be fixed, if project configured with
- --enable-static --enable-shared than "make" must create both static and
shared or fail. Just because I requested both, not some combination up
to libtool choice.

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

iQEcBAEBCAAGBQJWveWvAAoJEL96xKXqwrr0q/gH/iD6iA6qgfzYFps7rJnIvEny
OBowzO2WguOQu2sNaD/6X3ketvu4Ooy/p3/k4eDIQm5MkDqu+M7ttuR7wELzApSf
G00Zzt0XFxvw4EWbOYWsotIiVDSYHc5CihvP1xmZJF8XvOqqekC5VMWP8C4FTOP7
mANQK6WqPvk/TdA2EN0CUNhf0bzYX9uXy1GWdgZxNd5ePzeJlDMkV1MgOf20pM/F
gazM7dp+oIBCUW9g6E5bvzcsFYTTe+f3hJWHHB3xShKyUnIcMMdk3dwGNGdcHCMo
DgIk4MYJE6PLc0wI0pEz6cFPfj7sSF0b3khQiT0b0PB6LU2ZJFZx7/d+RbKMxjw=
=cuCE
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Nick Bowler]

On 2/12/16, Evgeny Grin  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12.02.2016 0:14, Nick Bowler wrote:
>> 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".
>
> Actually, no. See:

Just to be sure:

> $ libtool --version
> libtool (GNU libtool) 2.4.6
> Written by Gordon Matzigkeit, 1996

Here you are running libtool installed on the system (by path lookup)...

[...]
> /bin/sh ../../libtool  --tag=CC   --mode=link gcc -fvisibility=hidden
[...]

...here you are running a copy of libtool bundled with a package.
They are not necessarily the same version.

It would be better to provide a test case that others can run.

Cheers,
  Nick

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

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
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
>> 

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12.02.2016 17:28, Nick Bowler wrote:
> On 2/12/16, Evgeny Grin  wrote:
>> Actually, no. See:
> 
> Just to be sure:
> Here you are running libtool installed on the system (by path lookup)...
> 
> [...]
>> /bin/sh ../../libtool  --tag=CC   --mode=link gcc -fvisibility=hidden
> [...]
> ...here you are running a copy of libtool bundled with a package.
> They are not necessarily the same version.
They are the same. Project was just reconfigured.
To be sure:
$ ./libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996


> It would be better to provide a test case that others can run.
I used GNU libmicrohttpd and added to libs extra static-only library by

$ make LIBS=-ltdbcstub103

You can even add non-existing library - result will be the same. Project
can be any autotools/libtool project.
I will create minimal working example later.

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

iQEcBAEBCAAGBQJWvhZqAAoJEL96xKXqwrr07LkH/2b+VRpZQVJuj0OXgrHdflab
aRGB62THtzvDH4Y9oNmMCj+2xlP7W0UsBjyp3wXsqkZeBdUZzQVa7rypjhBCu5Go
lcCGRfHkMJaU62tZUJkHUcvqwrSix7NOPRKszpFUNy6XbKcK5ytIxs8rNe2xRVQj
SSXxtkJe6ZxNJnCnRegbnl2vwE5kT4BmudHpRiff+ZVtg0dCHQCDJz3u56WZppyn
oE0R/HcXtIa3F/2DU4fwnZ1IdUVBr3ptLGT5esWgJJONMJgLPL/WR4Vh7t516qmr
V7ZSXIizhKL78MWAZMz3VvY11zl0PB5bzH2TymoGTVTfBOOJCGllS5YACt22ImM=
=ggpi
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12.02.2016 0:53, Bob Friesenhahn wrote:
> 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".
'enable' also implies 'produce result or fail is result is not possible'.
For example, if GCC is configured with "--enable-tls" than TLS will be
enabled or GCC will not be built. Same for any other "enable" option. If
something is enabled, than enabled option must be present in result if
"make" finished without an error, no matter what is printed during building.
Currently "--enable-shared" is the *ONLY* exception. It contradicts all
other options.

If some package cannot be built as shared library, than libtool can
print recommendation to try to rebuild it as static library. As package
must be rebuild as static.
Currently libtool is not helping at this moment. Instead, libtool makes
building more difficult is it hiding real errors.
A simple example: you are building a set of 20 depend libs for some
application (I'm working on Kodi (ex-XBMC) and it's a normal process for
release). Libs have inter-dependencies and build up in specific order.
If one of the first lib was accidentally failed to build as shared than
all dependent libs was not build as shared too. And this will not be
detected in the middle of process as "make" succeed. Libtool hides the
failure and time of long process of creating all lib chain was wasted.

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

iQEcBAEBCAAGBQJWvgPBAAoJEL96xKXqwrr06xUH+wXeTfpH+m5HO9qAS30AXjs2
YZcQxQfncDxec5pRCwpfCqXii8bnhne+kOXeVjDtPugQkCt6fQ66G3oftYYZTpmg
PyPJoyGd6s7jogsUYL6ceTmpp5LH/GJ+Yt/lFINlgUcr0vxJBxHlhuSi3xhIpLK9
IEoIyqoVX+yk3hnvNNRbzXVzhOC0FolHkELHlvNXJAk1SGXC774LUGWJ7Ll1HzRu
yhQPEjqLXqobXvJauFgAeSgX+HNp2twDLQdvTC/TTLPINuJt+jU+QTN3YgjbiCTh
gRdhRiVbOY4wB4JReGBLiNXk7uE1z8UDNTiOqc48cIamhpEX9+hEtC7JVkEC3fY=
=SYWA
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 12.02.2016 20:29, Evgeny Grin wrote:
> 
> 
> On 12.02.2016 17:28, Nick Bowler wrote:
>> On 2/12/16, Evgeny Grin  wrote:
>>> Actually, no. See:
> 
>> Just to be sure:
>> Here you are running libtool installed on the system (by path lookup)...
> 
>> [...]
>>> /bin/sh ../../libtool  --tag=CC   --mode=link gcc -fvisibility=hidden
>> [...]
>> ...here you are running a copy of libtool bundled with a package.
>> They are not necessarily the same version.
> They are the same. Project was just reconfigured.
> To be sure:
> $ ./libtool --version
> libtool (GNU libtool) 2.4.6
> Written by Gordon Matzigkeit, 1996
> 
> 
>> It would be better to provide a test case that others can run.
> I used GNU libmicrohttpd and added to libs extra static-only library by
> 
> $ make LIBS=-ltdbcstub103
> 
> You can even add non-existing library - result will be the same. Project
> can be any autotools/libtool project.
> I will create minimal working example later.

Minimal example:
configure.ac
- 
AC_INIT([libtool_test_01],[0.1.0],[k...@narod.ru])
AM_INIT_AUTOMAKE([foreign])
LT_INIT([win32-dll])
AC_CONFIG_MACRO_DIR([m4])
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
LDFLAGS="$LDFLAGS -no-undefined"
AC_OUTPUT
- 

Makefile.am
- 
ACLOCAL_AMFLAGS = -I m4

lib_LTLIBRARIES = libtool_test_01.la

libtool_test_01_la_SOURCES = libtool_test_01.c
- 

libtool_test_01.c
- 
__declspec(dllexport) int simple_func(int a)
{ return a + 2; }
- 

Run:
$ mkdir m4
$ autoreconf -i
$ ./configure --disable-static
$ make

Build lib fine. But:
$ make clean
$ make LIBS=-lnonexistlib
{skip}
*** 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.

Versions:
$ ./libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996

$ autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.

$ automake --version
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.

$ libtoolize --version
libtoolize (GNU libtool) 2.4.6
Written by Gary V. Vaughan , 2003


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

iQEcBAEBCAAGBQJWvjfQAAoJEL96xKXqwrr0gEIH/jd3sBgGp2Lo2ompPwd90kep
aVCzfeebBF3ABuwZ3VNTL/jEurPPSWL3sH9OAuef9wnZSOgWC0s4qtNxj6tsqaSB
+tEmN6bmr4YdQyljz6MqT2Hb54IL6FU1Yp9zHweHuBVodRFJBExUFBHjfoT7P7ew
PES3aeSsEAXziK0t8qqN8MpYiq4FN595tRcy9yFpzbzSuFn4Icmt8GjybcubT+pX
lgZJ5DRrdDeiamGnLVpOTNlA+5E22hYw5wVuEScOjxVXJj+uuxFvuGJDJlez9wjj
tlwNHj0X+bMm6GLxSp/p9PvqQ6jH2kInO/SuoU7T0DCDcDofJ2XTIceNnXjbM+w=
=F7e6
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Vadim Zeitlin]

Peter Rosin  lysator.liu.se> writes:

> On 2016-02-11 00:38, Bob Friesenhahn wrote:
> > 
> > Also, "-no-undefined" does not indicate if the library has undefined
> > symbols (many DLLs have undefined symbols).

 Sorry but this is just completely incorrect as written. It's very probable
that you meant something else from what you wrote, but just to avoid
creating even more confusion in this discussion I'd like to ensure that we
all agree and understand that DLLs (as in "Windows dynamically loaded
libraries") never have any undefined symbols, this is the whole point.

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

 This is, of course, a bug. I don't even know if it's worth continuing to
argue because I don't have anything new to add to what I had already
written and it is IMO quite obvious to any user of libtool that it should
imply it, yet most people here seem to consider it as a feature.

 Really, how exactly can the fact that the libtool option with the same
name as a linker option doesn't work in the same way be rationalized?
Especially when libtool is known to reuse the linker options in other cases
(e.g. -shared, -static, ...)? What possible advantage can there be in
allowing to create shared libraries with undefined symbols even if the
libtool library uses -no-undefined?

> I.e. If you add libtool -no-undefined, then the *only* thing that changes
> is that libtool actually attempts the shared build.

 This behaviour is completely nonsensical as well. There is already
--enable-shared for this! Libtool should attempt the shared build if it's
enabled.

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

 Or it won't work, but you'll learn about it when the library can't be
loaded on the user's system. Which is, of course, vastly preferable to
getting a link error if libtool passed --no-undefined to linker as every
sane person would expect it to do.

> Conditionally adding -no-undefined for systems where it matters is overly
> defensive.

 Sorry, what does this mean exactly? It's being said that libtool should
leave the control to the application developer. If the application
developer decided to use -no-undefined, why doesn't libtool pass it on to
the linker? Could the application developer intention really be anything
other than this?

 And, conversely, if you insist that libtool -no-undefined should not imply
--no-undefined for ld and should just enable the shared library build, why
is this option used instead of --enable-shared which would seem to be much
better suited to be the option which, well, enables shared libraries?

 I really don't know how to argue against this because whichever way I try
to understand the current libtool behaviour it just doesn't make any sense...

> Repeat after me:
> 
> libtool -no-undefined is not at all the same thing as ld --no-undefined.

 I don't want to repeat it, I want to change this and make -no-undefined
option in a way a reasonable person might expect it to.

 Regards,
VZ



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

Re: MSW DLLs support in libtool

[Bob Friesenhahn]

On Fri, 12 Feb 2016, Evgeny Grin wrote:


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.


We don't do this sort of thing since we have no control over the 
future and don't know what the future will bring.  So we use generic 
options.  If we try to guess what the future may bring then we may 
guess wrong and someone will take us to task about our bad decisions.


For AIX, there is a build mode where shared libraries are more like 
GNU Linux and not like DLLs.



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


As previously explained, it is more likely to lead to compilation 
success for packages which have not been crafted/tuned to succeed on 
targets where -no-undefined makes a difference.


A core Autotools principle is that the person compiling the software 
should be in control as much as possible.  This includes people who 
just received a tarball and are not the developer of the software. 
Another core principle is that defaulting to imperfect success is 
better than utter failure.


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

[Vadim Zeitlin]

Simon Richter  hogyros.de> writes:

> On 10.02.2016 17:49, Vadim Zeitlin wrote:
> 
> > *** Warning: Trying to link with static lib archive
/opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a.
> > *** I have the capability to make that library automatically link in when
> > *** you link to this library.  But I can only do this if you have a
> > *** shared version of the library, which you do not appear to have
> > *** because the file extensions .a of this argument makes me believe
> > *** that it is just a static archive that I should not use here.
> 
> Linking a static library into a shared library will only ever work on
> Windows [...]

 Yes, and this is fine. I'll obviously have shared libraries on the other
systems, but why should I have them for Windows too when I don't need them
there?

> On Windows, that is the default behaviour -- all PE binaries are
> completely relocatable, mostly because Windows 3.11 required that. On
> Linux for i386, the dynamic linker supports relocations outside the GOT
> and PIC, which creates unshareable pages and generally sucks, but was
> necessary to port some software back then.

 Thanks, I know all this but it's not really relevant here anyhow. The fact
is that linking non PIC into DLLs works perfectly fine under Windows,
always did and always will. So it makes absolutely no sense whatsoever to
check whether a library contains PIC or not when targeting Windows: you're
checking for something that is completely irrelevant as everything is going
to work no matter what the result of the check is. Except that it currently
doesn't because the check fails and so the shared library is not being
created.

 If this doesn't fit your definition of irony, I don't know what does.

> So support for linking shared into static libraries is essentially
> "win32 only", but creating a special mode for that would make no sense,

 Yes, we agree on this. Last thing we need is an additional mode in
libtool. Instead libtool should just unconditionally skip the check for PIC
when targeting Windows, it's as simple as that. What possible purpose could
there be in checking something that we don't care about anyhow?

> because then the source would no longer be portable and we wouldn't need
> libtool.

 This is a complete non sequitur. My code is quite portable but it uses
static Windows libraries and shared libraries under Unix. So what?

> Boost is a little bit special because they encode the version number and
> several compiler options in the DLL name. Does it link correctly if you
> use the fully decorated name (because that is also what you'd use on Linux)?

 I'm building Boost static libraries manually myself because their
abomination of bjam doesn't support cross-compiling to Windows correctly,
at least in the ancient version of Boost I have to use, so they don't use
decorated names. But this is again irrelevant, even if I can work around
the problem somehow, this problem shouldn't exist in the first place.


 Several concrete questions in this thread asking for any benefits of the
current libtool behaviour went unanswered, but let me try once again
nevertheless: do you see any useful consequences of performing the check
for PIC when targeting Windows in libtool? If you do, what are they
exactly? And if you don't, why do you still think it should be done?

 Thanks in advance,
VZ



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

Re: MSW DLLs support in libtool

[Peter Rosin]

On 2016-02-12 22:12, Vadim Zeitlin wrote:
>  Several concrete questions in this thread asking for any benefits of the
> current libtool behaviour went unanswered, but let me try once again
> nevertheless: do you see any useful consequences of performing the check
> for PIC when targeting Windows in libtool? If you do, what are they
> exactly? And if you don't, why do you still think it should be done?

To this specific question, the things that I can think of is if two DLLs
(or the app itself) links with slightly different versions of the same
static library, that might cause strange bugs. Or if different DLLs
link to the same static malloc library and that that in turn produces
multiple heaps causing pain should pointers be passed across the DLL
boundaries.

If libtool should be in the business of protecting from such disasters
is another matter...

Cheers,
Peter

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

Re: MSW DLLs support in libtool

[Peter Rosin]

On 2016-02-12 21:59, Vadim Zeitlin wrote:
> Peter Rosin writes:
>> On 2016-02-11 00:38, Bob Friesenhahn wrote:
>>> 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.
> 
>  This is, of course, a bug. I don't even know if it's worth continuing to
> argue because I don't have anything new to add to what I had already
> written and it is IMO quite obvious to any user of libtool that it should
> imply it, yet most people here seem to consider it as a feature.

The feature here is to not break packages. Changing libtool -no-undefined
to imply ld --no-undefined -- at this point -- is not an option IMHO.

Also, libtool added -no-undefined before ld added --no-undefined, so some
might argue that you are barking up the wrong tree if you think things
are inconsistent. Not that shifting blame is going solve anything...

Cheers,
Peter

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

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

Re: MSW DLLs support in libtool

[Nick Bowler]

On 2/10/16, Bob Friesenhahn  wrote:
> On Wed, 10 Feb 2016, Peter Rosin wrote:
>> I agree wholeheartedly with the notion that --disable-static should end
>> up in a failure and not somehow degrade to a static build anyway. I
>
> Is this not the case?  I have seen builds on Windows fail due to using
> --disable-static.

I just tested it on a library which does not specify -no-undefined, and
therefore won't be built as a shared lib on Windows:

  ./configure
  [...]
  libtool: warning: undefined symbols not allowed in i486-pc-mingw32
shared libraries; building static only

  ./configure --disable-static
  [...]
  libtool:   error: can't build i486-pc-mingw32 shared library unless
-no-undefined is specified

So things fail as expected, although the error message seems a bit poor.

Cheers,
  Nick

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

Re: MSW DLLs support in libtool

[Nick Bowler]

On 2/10/16, Peter Rosin  wrote:
> Personally, I don't get why the win32 option exist at all.  I see no
> reason to discriminate against Windows like that. Make the no-windows-
> purists opt out with no-win32 (or whatever) instead.

What does the win32-dll option actually do?  I just learned about it now...
Using mingw32 it appears to not be necessary.

Is it really just about saying whether the __declspec annotations are
used or not, similar in spirit to -no-undefined (but package wide)?  I
get that the mingw32 has an "auto-import" feature so the annotations are
not generally needed, so maybe this is why it works anyway.

Regards,
  Nick

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWu5y/AAoJEL96xKXqwrr0Q1MIAMAZvkIk2DFlIuxQTKmlh/X5
hGIKSvbs2lsHh6wuy3REIVRfSnjoVOM/q/jHDV0+2czAkW7zg6yhILh8jPO//AHT
wW8ZASyEFm1llwvy8RDSI3sIQEIn71MC0SjejuDelFFRfIm3p9yyDFKsoM7UEyt1
qfFazfVO/T1Kuc3Rpc7zsUEUeFGhWLR5jtw2QP1yZFwnDYrnj5Si+ObKeKpBD0uj
wF3lHEQq21cEjmlZhkjLrm7EfAPJDzgQ1SsfZlmcg5R9AWPyxNDghNP/RXu6e8Lx
pHoPtRu74zZBxWiEDYgjVmPb4MVqx44SVftpnXuTzdV0fcRFW04SD9ciT+a8jM0=
=pU+Q
-END PGP SIGNATURE-

___
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 6:29, Bob Friesenhahn wrote:
> On Wed, 10 Feb 2016, Vadim Zeitlin wrote:
>>
>> Sorry but this is just not true for the MSW DLLs. If the libtool user
>> tries to build a DLL, you can safely assume that it will not have
>> undefined
>> symbols. Anything else just doesn't make sense because it would always
>> result in an error. Again, this is different from the traditional Unix
>> shared libraries.
>
> Why do you say this?  Most software built using libtool still comes from
> Unix type systems.  Without the existing behavior it would be difficult
> to take a program developed on a Unix type system and just compile it
> under Windows.  It is thought that errors are bad and successful
> compilation is good.
Do you mean creating static libs when shared lib was requested instead
of failing?
In this case errors are good, because requested operation was not
performed. Any when some program later failed to compile/run, it's much
harder to find source of problem because was no indication of failed
shared lib creation. Moreover, some libs designed to be compiled as
shared lib, may not function properly if used as static. Especially if
DllMain() is used. In this case it will be even more harder to find
what's wrong even if some program that uses lib is compiled and run.

That's look a bit weird. It's like I compiled something for ARM64, but
compiler generated code for ARM, because compiler not sure that ARM64
code can be generated (and even didn't try to generate ARM64 code).
Same libtool does for shared and static libs.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWu50hAAoJEL96xKXqwrr05RwH/0PeQCHUKgtLYffiMXTjoXGb
fPuZSbVLFnrPE+Ol6v4paWzakVYoaBwHc2fNBJ3f9OEznsbFXs3SE+/D7bDdyN7v
K8Wc2B4Q4+YcHKGgp8lj+U+nh5V+cNwSkIoQUkJ7Zgh1WsQx9WUQCvZL1IQUb+z2
xIt/I7M80RKRfmqlwsqtjFkfLobS5npSZUxDpcsJ37ZiLEdgwAHkmuUrVRE8EnUs
vyx3Hls+NRQA4vu7TVJY3C6YNO82LyLY+W3nKifN3bWHXTg0HUNQKk4WyiZaqlu8
nRfpt86o7LTPNlfI4vXFZiJX3F8U2vlzDtnTOqhzT/fHoULO8nafIQczRQl1IUk=
=q1Ji
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Simon Richter]

Hi,

On 10.02.2016 17:49, Vadim Zeitlin wrote:

> *** Warning: Trying to link with static lib archive 
> /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a.
> *** I have the capability to make that library automatically link in when
> *** you link to this library.  But I can only do this if you have a
> *** shared version of the library, which you do not appear to have
> *** because the file extensions .a of this argument makes me believe
> *** that it is just a static archive that I should not use here.

Linking a static library into a shared library will only ever work on
Windows, and (with lots of warnings) Linux on 32-bit x86, because these
two platforms are the only ones supporting run-time relocation of code
that wasn't compiled to be position independent.

On Windows, that is the default behaviour -- all PE binaries are
completely relocatable, mostly because Windows 3.11 required that. On
Linux for i386, the dynamic linker supports relocations outside the GOT
and PIC, which creates unshareable pages and generally sucks, but was
necessary to port some software back then.

So support for linking shared into static libraries is essentially
"win32 only", but creating a special mode for that would make no sense,
because then the source would no longer be portable and we wouldn't need
libtool. The extra hoops for creating Windows DLLs are due to additional
constraints on the source code, but this would be relaxing a constraint
that exists on all platforms but one.

Libtool should in principle find the import library for the DLL and link
against that.

Boost is a little bit special because they encode the version number and
several compiler options in the DLL name. Does it link correctly if you
use the fully decorated name (because that is also what you'd use on Linux)?

   Simon



signature.asc
Description: OpenPGP digital signature
___
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 17:38, Bob Friesenhahn wrote:
> On Wed, 10 Feb 2016, Peter Rosin wrote:
>> I agree wholeheartedly with the notion that --disable-static should e
nd
>> up in a failure and not somehow degrade to a static build anyway. I
> Is this not the case?  I have seen builds on Windows fail due to using
> --disable-static.
> 
> Libtool is not well optimized for Windows or even GNU Linux.  Instead 
it
> provides a working generalized solution which is usually "good enough"
.
Let's make Libtool even better. :)

I suggest to add LT_INIT options "no-fallback-to-static",
"fallback-to-static" and add warning when producing static instead of
shared that this behaviour can be changed in future versions of libtool.
Later make "no-fallback-..." default.
Is it possible that such patch will be accepted for Libtool?

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

iQEcBAEBCAAGBQJWu5hdAAoJEL96xKXqwrr0BTUH/0YtsVO4A1MxME2Ai6yuEylI
31H5jn7fvRXXIH2DNJJniT5A0jFgOiUzQHcO2AzQV1D0XLiwcc/6v7s7UP0xi3VR
Upj8UNhP/wiMaCzh2R1fSAG5KyQlk5ebwpY/d4P+WINRun5wkg8+0ig7eTFrt0/3
mzIRjj9LKlU1JcnAZXLo1onpoKap6C6HR89WDDx9Q6rbMjcop4GPaa6XLEFRU2fb
rElF+yekxXwly8NmzdWOY6pptP9HdtTiU8iisUZlT2jHdNJx1m9vu2NTZ3zxJFXE
67j9Zv0WuFib5Xk1894QRCw7j19wUfd/XOROJgOlWWGB9latL7ue6FJQIHdzI/U=
=QxVZ
-END PGP SIGNATURE-

___
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:23, Nick Bowler wrote:
> Libtool will transparently handles this, by not building shared
> libraries when it cannot do so.  The idea is that packages can
> still be useful without shared library support.  In my experience,
> this works very well.
I my experience, this works not really well.
If set of .dlls are prepared for some app then you'll get error only
when compiling main application, not set of libs. This is really
confusing, because all libs were created successfully (not actually,
because libtool built static instead of shared and do not report error).
This is good for some one-shot testing of proof-of-concept, but really
very bad for production.
If package is configured with some (currently not existing) option
"--enable-any-usable-form" it's OK to fallback to static even if it
wasn't requested.
But without it, this behaviour is a bad thing. Currently erroneously
built packages can be published as good packages during automated
rebuild process because even running test suite will not detect any error.
Because of it, I saw advises like: "I don't know why .dll is no created
because make finished without any error. Just go to src/somedir and run
dlltoll with *.o. This will create usable .dll."

> The -no-undefined option is a signal to libtool: "This library is
> compatible with systems that don't support undefined symbols in shared
> libraries".  It affects libtool's decision on whether or not a shared
> library is possible.
We signalled this already by LT_INIT([win32-dll]). Why we need to signal
this second time?

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

iQEcBAEBCAAGBQJWu5xIAAoJEL96xKXqwrr0CRoH/1JtIpKNe2w7EQlUxK3qh07Y
MGRbagr8YTvI0cV0bb2qwXT5H/2DKwkNoIg2SAO1avTvNYjDX4LWIUkNNVD+nlDJ
hbGeSu0eQ0VX6oH9B3fHD0XZb8WxINk3W+gGGobM0XbXyGHccUa2lBdK9/D00wn9
QrLGGoPuL0D0R+QGAXmgKwixz3rkHFmLkhbM1kYbDIzTEGVF7vCsm5MNBtQcrED/
F12oBkBiAXwiHcdPwqr/5cVQD4qgy+WxJ0bD/Dptg7cPny7FBKRXHDf2CgHWPOl/
lZMQ+TxKI6AfYNBbqQORd3O50vAlRx4nedG1672lzQ9TfKrznMmFplU+1AXDGBI=
=wXQv
-END PGP SIGNATURE-

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWu4/KAAoJEL96xKXqwrr0U+EIAMMG6pE5nmihPNJVFvgr9Uxu
VSDStJDaqeuoir+gc7VUKEV9tLgVC5Q6qlv4ltxLWhIPWoqHV41XFxrXUWTCz6HZ
pptHEeZBwLULaENswPwfk+n2K+BfLq1Xyy2lLC4rwy4i3K73H+TzVv/gs903mfBP
y9a8jvjlXimNJseePeG1HL9m7tsQELkHQdI/nOOuy6MItMdcCQfco3DE9wt49tnK
Npw8dQp0DoCRlqB8zH6HXYdnmEz5Nd1467ziiTR++LH31Zpr8BH9gtNVsNbjVA/g
amMSqjBzFUNPjvdBSyZJoUnoSE+/g1/FDD8rqgdDURkMa9fhMFCP92BKg0gCkW4=
=8wp6
-END PGP SIGNATURE-

___
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 19:49, Vadim Zeitlin wrote:
>  But the problem with not being able to link in static libraries into a DLL
> under MSW (the point (3) of the post which started this thread and the one
> which I said was the most important for me) remains, even with the latest
> master (2.4.6.24-5944f).
Agree, this can be really useful. Some small libs can be created as
static to be included in shared lib later. W32 have no problem at all if
same static lib is included in several shared libs and in application at
the same time. If this can't be enabled by default, could we add some
(configure, LTLDFLAGS?) flag to enable this functionality? I can provide
patch.

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

iQEcBAEBCAAGBQJWu6MrAAoJEL96xKXqwrr0I9EH+QFbpJaxJrUTW6aKfTEVEz/h
RaKv5vkK1X53aTaKIk40Ow7zkduy+LZ60g/DdZnbMUcSI9FVMfC1kO8wYmF7js8+
AlCAz6wsDhI4o7De53Og1E3x9e+iZfQHiiC1aKhi6DOxY7PuCA+xfp+5KJjG6PRz
U3yAdTSYu9piqrUB3JTuQF2I5UVjt1auGD5Dsrbc4vJy9e6ylMPnKKTuiYJfveKZ
9TdLxPxu/NmPvvvHO6aDacCcAlBJOO8M7sGvDOQ+SrwNsM1e0DyAHSBbpPlczWA7
PiB1SYxiIKE+J7T7cEv3q8yAEvwwZsY3I8vvgpwGe2tsr3NMjqYdYgXcjpu/3tk=
=iUv9
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 10.02.2016 6:29, Bob Friesenhahn wrote:
> On Wed, 10 Feb 2016, Vadim Zeitlin wrote:
>>
>> Sorry but this is just not true for the MSW DLLs. If the libtool user
>> tries to build a DLL, you can safely assume that it will not have
>> undefined
>> symbols. Anything else just doesn't make sense because it would always
>> result in an error. Again, this is different from the traditional Unix
>> shared libraries.
> 
> Why do you say this?  Most software built using libtool still comes from
> Unix type systems.  Without the existing behavior it would be difficult
> to take a program developed on a Unix type system and just compile it
> under Windows.  It is thought that errors are bad and successful
> compilation is good.
Do you mean creating static libs when shared lib was requested instead
of failing?
In this case errors are good, because requested operation was not
performed. Any when some program later failed to compile/run, it's much
harder to find source of problem because was no indication of failed
shared lib creation. Moreover, some libs designed to be compiled as
shared lib, may not function properly if used as static. Especially if
DllMain() is used. In this case it will be even more harder to find
what's wrong even if some program that uses lib is compiled and run.

That's look a bit weird. It's like I compiled something for ARM64, but
compiler generated code for ARM, because compiler not sure that ARM64
code can be generated (and even didn't try to generate ARM64 code).
Same libtool does for shared and static libs.

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

iQIcBAEBCAAGBQJWu498AAoJEN665qOCrkO/XnYQAIS+s1N9M5wgQ+I3zz+E9oMD
wKDfQb5M2VpxJRqMvxIL80GyZ7gAd8rV55Y1u2HGRtHe1N91lxPv60BSSlGrNP57
2MjXidGXVEsKKyHkhIrsH1m79xMLAMC6/Zicm5GskyOuCYqjx5i7PeBGHU6g0uxi
4zWYCaLVgYS39ITwVfpCRqTF87KXfihmUqAI0cWG6k2g86bjQ0bkhMpDIK4l6hRw
+LQ/X5tqNHqoW0HJkaCpo0qqgppIrP3cyQfNde4l4MPmf90H35yIWTPKqepjFDEF
CX7BEspDcqHAbSiSvKdtYJN4dU8KhJb8JryDVlSaPiPFGtuezCT0hMMMZJVARPzj
hPr03Bv4jFilQVG8Fl7Nb9ExCweaTwNMe32DzDQjmYRsVrGRJDRft3n04LJ61d1Q
fSAAICyAz0RggKjR+r10qE2QhFEhjZlXIBglOFTYkccQibUSrGhuX9iDC9TobdGb
ig2B2AeWASBgpj0k8J4NtTO1KY5Z4S+Wplpn45D5lsOl4iCB6Lh1iXrXD+FcMukz
kOGULoygrQC8cGjbEAHR7YRq+4mySHEEQg62CjIqhIPWeoWoNeruoiPz0o0w8r4j
1IhwKHO0vOS9cfETHD0a1UQsdnJmYyOH5FwnQIFlGbzKJJiyO/jniRAKPcpHuDQE
HSLfIO7R2LAXtTwZpVEQ
=shXP
-END PGP SIGNATURE-

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

Re: MSW DLLs support in libtool

[Peter Rosin]

Hi!

[Replying to various things across the thread]

On 2016-02-10 04:53, Vadim Zeitlin wrote:
> On Tue, 9 Feb 2016 21:29:23 -0600 (CST) Bob Friesenhahn 
>  wrote:
> 
> BF> On Wed, 10 Feb 2016, Vadim Zeitlin wrote:
> BF> >
> BF> > Sorry but this is just not true for the MSW DLLs. If the libtool user
> BF> > tries to build a DLL, you can safely assume that it will not have 
> undefined
> BF> > symbols. Anything else just doesn't make sense because it would always
> BF> > result in an error. Again, this is different from the traditional Unix
> BF> > shared libraries.
> BF> 
> BF> Why do you say this?  Most software built using libtool still comes 
> BF> from Unix type systems.
> 
>  And almost all of it wouldn't compile under MSW. I think it's reasonable
> to assume that if an effort was made to port some piece of software to MSW,
> it wouldn't have any undefined symbols in its DLLs.
> 
>  Of course, if you really want to just compile it and don't care whether
> you get static or shared libraries, nothing prevents you from using
> --disable-shared and building static libraries only. Contrast this with the
> current situation when using --disable-static doesn't change anything at
> all and static libraries are still being produced by libtool.
> 
> BF> Without the existing behavior it would be difficult to take a program
> BF> developed on a Unix type system and just compile it under Windows.
> 
>  In practice this is never going to work for any non-trivial program.

You appear confused (as almost everybody else) about what -no-undefined
means to libtool. The confusion stems from(?) the similarly named linker
option, --no-undefined, which apparently does what people expect from
the libtool -no-undefined option. Alas, the fact is that libtool
-no-undefined is not a request to complain if there are undefined
symbols (which, as you say, happens automatically on Windows), it is a
declaration by the library author that there are in fact no undefined
symbols in the library. The situation is unfortunate, and I also hate
the bad libtool default.

As for your point about non-trivial programs not working without
special treatment, there are a large body of packages that build just
fine using Cygwin on-top of Windows, without much in the way of special
treatment. Cygwin also suffers the from the cursed -no-undefined mess,
since the underlying system is Windows and DLLs cannot have undefined
symbols. My point here is that are a non-trivial amount of packages that
indeed builds fine on Cygwin where the only "porting effort" is that
silly -no-undefined option. So, your "is never going to work" is simply
not true, all the linking limitations mentioned by Bob applies equally
to Cygwin and native Windows, but compiling is so much easier given
the Cygwin POSIX support, which of course is lacking on native Windows.

I agree wholeheartedly with the notion that --disable-static should end
up in a failure and not somehow degrade to a static build anyway. I
also recognize your frustration. However, one important thing to consider
when it comes to Windows support is that many many package maintainers
are sorely tired of all the special casing, do not bother getting a
working build setup, etc etc etc. Windows support is sketchy in a lot of
places. Changing stuff in Libtool to help this situation is therefore
extremely delicate, you risk breaking fragile workarounds that are
rarely tested, if ever. If you change things, you should be quite sure
that it does not cause regressions.

Another angle on this topic is that I believe that the win32 LT_INIT
option was added to not inflate configure overhead for packages not
supporting Windows (i.e. conforming to your mindset that packages
don't work w/o special treatment anyway). This is still a factor.
Systems like buildroot and gentoo, where packages are built over and
over, do not like if when configure times grow. Making the win32 option
the default would perhaps regress their build times? I think this
point is moot, because I think the overhead of the win32 LT_INIT option
is quite insignificant, but I don't know that. Maybe it drags in some
extra file or something? Extra files could be an eye-sore to some
puritan. Personally, I don't get why the win32 option exist at all.
I see no reason to discriminate against Windows like that. Make the
no-windows-purists opt out with no-win32 (or whatever) instead.

> BF> It is thought that errors are bad and successful compilation is good.
> 
>  I completely and utterly disagree with this. Silently doing the wrong
> thing is by far a worse thing to do than giving a clear error indicating
> what needs to be done to correct it. Especially if there is no way to
> override this "smart" behaviour.
> 
>  To be blunt, libtool support for MSW looks like a hack. It has no real
> logic and just blindly tries to do everything to produce something,
> whatever it is. It might indeed be sufficient if you're just compiling
> "Hello 

Re: MSW DLLs support in libtool

[Bob Friesenhahn]

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.


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/9/16, Vadim Zeitlin  wrote:
> I'd like to create Windows binaries for my software from Linux, which
> includes creating a couple of DLLs and EXEs that use them. This is not too
> difficult to do with just manual makefiles as both the cross-compiler and
> linker work just fine. Libtool is another matter entirely however:
>
> 1. By default, libtool _silently_ doesn't create DLLs at all and
>"win32-dll" LT_INIT() option needs to be used just to give it a chance
>to fail. This default looks very unfortunate to me, static libraries
>are almost never the right replacement for the DLLs and finding this
>option when you don't know about it already is not obvious. I'd
>strongly prefer if this option were enabled by default but failing that
>libtool should at least give a noticeable warning if the target
>platform is MSW and it is not enabled and require using no-win32-dll
>explicitly to disable it.

Here's the thing.  Libtool is, by default, designed to transparently
support the case where building a shared library is not possible.

If you don't want to build static libraries, configure with
--disable-static.  Then you will get errors whenever building
a shared library is not possible.

If your package absolutely does not support static libraries at all, you
can pass disable-static to LT_INIT (or controlled on a per-library basis
with -shared).  Nobody will be able to build your package where shared
libraries are not possible.

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

Because unless you tell it, libtool has no way to know a priori whether
a library will have undefined symbols or not.  In order to transparently
fall back to static libraries in this case libtool requires this
information.

In retrospect, the default (assume undefined symbols are possible) was
probably a bad choice, because undefined symbols in libraries are rarely
used.  Thus, almost all libraries need to specify -no-undefined.  But
this can't be changed now without causing regressions.

> 3. If you thought that making the two changes above would be enough to
>finally create the DLLs instead of static libraries, as I did, you would
>be wrong because if any of the DLLs link with any static libraries, it
>will still create static libraries (albeit not silently this time)
>because it fails to check if it can link link the DLL with these static
>libraries. This is extremely frustrating because it has absolutely no
>reason to be checking for anything at all, unlike some other platforms
>(e.g. Linux x86-64), there are no restrictions whatsoever on the
>libraries that the DLLs can be linked with as they don't need to contain
>PIC code under MSW. After some digging around I could work around this
>by doing "lt_cv_deplibs_check_method=pass_all" in configure before
>LT_INIT() but this was far from obvious to find and, of course, not
>guaranteed to work in the future. Why isn't "pass_all" the default (and
>only possibility) for the MSW targets?

The nasty warning when you link shared libraries against static libtool
libraries is because this arrangement is not portable, and libtool is
designed to facilitate portable packages.

If you still want to do it anyway, the warnings can be avoided by
passing libtool the .a file directly.  Better to use shared libtool
libraries (or libtool convenience libraries) if at all possible.

> 4. After all the previous steps I could finally cajole libtool into
>building the DLLs for my lib_LTLIBRARIES but it still silently builds
>static libraries for all my noinst_LTLIBRARIES and I have no idea why.
>I'm giving up for now because this is less critical, but it would still
>need to be fixed if I want to continue using libtool instead of just
>abandoning it (and, by necessity, automake) and going back to hand
>written makefiles.

These libraries are libtool convenience libraries.  They are a bit
different from normal libraries, as they cannot be installed (they are
little more than a way to avoid passing a whole bunch of object
filenames to libtool when linking).

[snip]

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

TBH I'm not sure what problem you are actually having. 

Re: MSW DLLs support in libtool

[Bob Friesenhahn]

On Tue, 9 Feb 2016, Nick Bowler wrote:


In retrospect, the default (assume undefined symbols are possible) was
probably a bad choice, because undefined symbols in libraries are rarely
used.  Thus, almost all libraries need to specify -no-undefined.  But
this can't be changed now without causing regressions.


This is not really true.  For example, the linker on GNU Linux 
implicility supplies libraries at link time (because of how they were 
built) and libtool has no way to know about library dependencies which 
are not listed in .la files.


Some GNU Linux distributions intentionally modify libtool such that 
dependency libraries are not included and they delete all .la files.


The reason for intentionally losing dependency information is because 
the specific dependencies cause packaging problems.


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