Forced static lib if any depend lib is static on win32

[Evgeny Grin]

Hi!

Win32 libs is forced to be static if any dened lib is not shared.
If it's done to prevent symbols conflicts on several shared libs with same 
static lib. But if DEF file is used or dllexport function attribute is used, ld 
will not export functions from static lib if no "--export-all-symbols" is 
specified. Same with -fvisibility=hidden on non-Win32 platforms.
Usually on Win32 libs are distributed in binary form and dll hell is a problem 
for projects with many depends libs as for example almost every lib use 
zlib.dll, but different zlib.dll is not abi compatible. So it can be wise to 
statically link libs for some shared lib.
Is it possible to support such configuration in libtool?

Best Wishes,
Evgeny

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

-no-undefined on Win32

[Evgeny Grin]

Hi,

It's strange for me that last line in following qoute from ltmain.in is 
commented out:
---
  # It is impossible to link a dll without this setting, and
  # we shouldn't force the makefile maintainer to figure out
  # what system we are compiling for in order to pass an extra
  # flag for every libtool invocation.
  # allow_undefined=no
---

Almost all project ported to Win32 already have "-no-undefined" options, but 
this always add more headache on porting to Win32.
If lib contains some undefined symbol, then dll will not be created regardless 
of using "-no-undefined".
If lib doesn't contain any undefined symbols, then dll can be created so why 
forcing use "-no-undefined"?

Best Wishes,
Evgeny

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

(almost) silent creation of static lib instead of dynamic linked lib

[Evgeny Grin]

Hi!

Libtool always build static lib if dynamic lib can't be created.
This behavior is inconsistent with other build tools. For example if GCC can't 
compile something, it fail with error.
If I need a shared lib, this doesn't mean that static lib will satisfy me.
When I run configure with "--enable-shared" (or shared enabled by default), I 
expect that "make" will build shared lib or fail with error.
Currently developers are forced to check "make" return code and additionally 
check for real presence of shared lib files.
I think that static lib must be built only if requested and shared lib must be 
built when it's requested.
I suggest to add new default configure switches "--enable-static=auto" and 
"--enable-shared=auto". If both are auto then libtool will try to make both 
static and shared and fail only if both static/shared can't be built. If any of 
static/shared are explicitly requested, libtool must fail if corresponding 
static/shared can't be built.

Best Wishes,
Evgeny

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

Passing flags with mode=link

[Evgeny Grin]

Hi,

I spend a few hours before I realized that libtool did not pass to linker flags 
other than -L -l -Wl, and -Xlinker. It's totally confusing as in compile mode 
libtool pass all flags to compiler.
Currently there are no way to pass flags like -static-libgcc to linker except 
editing makefile/configure.
Common way of setting required flags by setting LDFLAGS before configure didn't 
work because simple flag "-static-libgcc" will be ignored by libtool and flag 
"-XCClinker -static-libgcc" will cause configure fail on GCC tests.
Moreover, currently many configure tests can be incorrect as configure test 
pure GCC/linker with LDFLAGS (and some flags can modify GCC/linker results) but 
during "make" stage libtool filter many linker flags and linker works not as 
configure expect.
I suggest to pass all flags to linker, as in compile mode.

Best Wishes,
Evgeny

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

Re: -no-undefined on Win32

[Evgeny Grin]

18.04.2014, 19:17, "Bob Friesenhahn" :
> Why does it create more headache when porting to Win32?  Using this
> option indicates that the project has been constructed in a way which
> will work on systems which do not allow undefined symbols.  Many
> projects (particularly those targeting only GNU/Linux because it is a
> popular operating system) are not suitably constructed and require
> adaptation.

As it's required mostly for Win32, project creators don't use this option by 
default. Moreover, to ensure maximum portability, this option often used 
conditionally for win32 only.
I can't get the idea, why libtool needs information that author is aware of 
undefined symbols (or aware of something else). This is inconsistent with other 
GNU tools. For example, GCC don't need information that author is aware of 
C++11 features. You can instruct GCC to use C++11 dialect or instruct to use 
C++03 dialect (and not use C++11 features).
I suggest to use the same logic for libtool. Use "-no-undefined" options to 
instruct linker to not use undefined symbols where it's possible to use 
undefined symbols. If some particular platform always need some compiler/linker 
option for shared lib then substitute required option automatically. The main 
idea of libtool (as I understand it) is simplification creation of static and 
shared lib, but currently this will make compilation more difficult than 
without libtool.

> Libtool always defaults to successful compilation and link, to the
> maximum extent possible.

That's nice, leave it to compiler and linker. If something can be compiled and 
linked, it will be compiled and linked. If it can't be, then compiler or linker 
will fail. Why giving up before even try?

-- 
Best Wishes,
Evgeny Grin

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

Re: Forced static lib if any depend lib is static on win32

[Evgeny Grin]

18.04.2014, 19:25, "Bob Friesenhahn" :
> For Win32 builds on my Windows system, I see that it is normal for
> DLLs to be named according to the major interface number.  For
> example, zlib (not created using libtool) is named "zlib1.dll" and
> libltdl (created using libtool) is named "libltdl-7.dll".  This is not
> as convenient as ELF versioning, but does prevent disaster.  Why is
> this not the case for your system?

For XBMC we have 41 depend precompiled lib, 4 of them depend on zlib dll, all 
of 4 depend on zlib1.dll, but each one on specific zlib version. And with some 
zlib versions some of depend dlls crash.
But it's just an example. Sometimes only a small fraction of lib functions is 
used, so it's better and wiser to statically link only those functions for 
shared lib and not redistribute heavy additional dll with your dll.
There are far more possibile good uses for static libs in shared libs.
MS dev tools allow any combinations of shared/static link, why libtool give 
worse possible options?

> Libtool convenience libraries do support DLL exports but this is
> because libtool built them and so it knows how they are built.  In
> fact, libtool convenience libraries are not used like libraries at all
> and are simply a convenient reference to a collection of object files
> wrapped in an archive.

Didn't see anything that prevent linking static libs in shared libs.
Additionally libtool can track if some particular lib use "dllexport"/def-files 
or simple export of all symbols.

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

Re: (almost) silent creation of static lib instead of dynamic linked lib

[Evgeny Grin]

18.04.2014, 19:12, "Bob Friesenhahn" :
> On Thu, 17 Apr 2014, Evgeny Grin wrote:
>>  Libtool always build static lib if dynamic lib can't be created.
>>  This behavior is inconsistent with other build tools. For example if GCC 
>> can't compile something, it fail with error.
>>  If I need a shared lib, this doesn't mean that static lib will satisfy me.
>>  When I run configure with "--enable-shared" (or shared enabled by default), 
>> I expect that "make" will build shared lib or fail with error.
> Did you try using --disable-static?  Enabling building shared
> libraries is not the same as disabling building static libraries.

Yes, with "--disable-static" libtool create only static lib if any depend lib 
is static.

But even with "--enable-static --enable-shared" I expect that libtool will fail 
in case that shared lib can't be created. 
GCC fail if it can't compile something, "make" fail if it can't build something 
(unless it explicitly instructed to ignore specific build error) and only 
libtool do not fail in case that something requested to be built can't be 
built. 
Why libtool think that static lib if enough for me if I configured to build a 
shared lib too?

-- 
Best Wishes,
Evgeny Grin

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

Re: Forced static lib if any depend lib is static on win32

[Evgeny Grin]

19.04.2014, 04:45, "JonY" <10wa...@gmail.com>:
> On 4/19/2014 03:31, Evgeny Grin wrote:
>>  For XBMC we have 41 depend precompiled lib, 4 of them depend on zlib dll, 
>> all of 4 depend on zlib1.dll, but each one on specific zlib version. And 
>> with some zlib versions some of depend dlls crash.
>>  But it's just an example. Sometimes only a small fraction of lib functions 
>> is used, so it's better and wiser to statically link only those functions 
>> for shared lib and not redistribute heavy additional dll with your dll.
>>  There are far more possibile good uses for static libs in shared libs.
>>  MS dev tools allow any combinations of shared/static link, why libtool give 
>> worse possible options?
>
> I think you should be cleaning house, instead of allowing random bits
> and bobs to connect together. The real problem is that you have 4
> incompatible versions of zlib1.dll in the first place.

Of course cleaning is required, but it's not always possible to simple rebuild 
some particular lib on Win32.
But I was talking about ability to link static in shared.

> Libtool is good at preventing multiple exports on win32, I have seen
> disasters where zlib is exported *multiple* times in different DLLs of
> the same project because the author does not know what is going on. At
> least it was a compatible and same version of zlib.

Right, it's nice idea to prevent static link for shared lib that blindly use 
"--export-all-symbols". But for well-designed libs that use dllexport attribute 
or def-file disallowing static libs is just obstacle.

>>  Didn't see anything that prevent linking static libs in shared libs.
>>  Additionally libtool can track if some particular lib use 
>> "dllexport"/def-files or simple export of all symbols.
>
> The difference is that convenience are purely used build time only, they
> are never ever installed. It is convenient when you have enough object
> files to overrun the OS command line length limit.
>
> I'm not sure you want convenient dlls that aren't installed, they don't
> make sense.

Ok, I got the advantage of libtool, but still don't understand why this should 
prevent linking static libs in well-designed shared lib?

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

Re: -no-undefined on Win32

[Evgeny Grin]

20.04.2014, 05:15, "Bob Friesenhahn" :
> On Fri, 18 Apr 2014, Evgeny Grin wrote:
>
>>>  Libtool always defaults to successful compilation and link, to the
>>>  maximum extent possible.
>>  That's nice, leave it to compiler and linker. If something can be compiled 
>> and linked, it will be compiled and linked. If it can't be, then compiler or 
>> linker will fail. Why giving up before even try?
>
> The GNU/Autoconf philosophy has always been that if software
> configures successfully that there should be a very high probability
> that the sofware will compile and work.  Success at compiling on
> several platforms should indicate that it is highly likely to also
> compile on other platforms (including platforms that the package
> authors don't have access to).
>
> If the software fails to compile, or fails to work, there is
> substantial possibility that the user won't know how to solve the
> problem.

Good. But requiring "-no-undefined" for Win32 flag lower probability of 
successful compile.
It's absolutely normal that something can be compiled on one system and can't 
be on other system. According autoconf paradigm, code should be compiled if it 
use platform supported features. So "configure" checks host and target 
platforms, compiler, linker and other things and do dirty work to create 
correct configuration in makefiles, libtool, compiler wrapper etc.
But if code designed to use some platform dependent features like epoll and 
epoll is not available on target platform then compile will fail.
So let's add to libtool "-disable-epoll" flag and let libtool fail if target 
platform don't support epoll and this flag is not specified.
It's far more logical to use flags like other GNU tools (GCC, binutils) use it. 
For example, this fictional flag "-disable-epoll" must prevent epoll usage on 
platforms that support epoll so code with epoll functions will fail to compile. 
On platforms without epoll support, code with epoll function will fail to 
comple in any case.
Undefined symbols is just one of platform features.

I can repeat again, let's simplify developer work instead of complicating. 
libtool must use "-no-undefined" for win32 targets automatically.

Best Wishes,
Evgeny

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

Re: Forced static lib if any depend lib is static on win32

[Evgeny Grin]

21.04.2014, 02:50, "JonY" <10wa...@gmail.com>:
> On 4/19/2014 09:22, Evgeny Grin wrote:
>
>>  19.04.2014, 04:45, "JonY":
>>>  On 4/19/2014 03:31, Evgeny Grin wrote:
>>>>   For XBMC we have 41 depend precompiled lib, 4 of them depend on zlib 
>>>> dll, all of 4 depend on zlib1.dll, but each one on specific zlib version. 
>>>> And with some zlib versions some of depend dlls crash.
>>>>   But it's just an example. Sometimes only a small fraction of lib 
>>>> functions is used, so it's better and wiser to statically link only those 
>>>> functions for shared lib and not redistribute heavy additional dll with 
>>>> your dll.
>>>>   There are far more possibile good uses for static libs in shared libs.
>>>>   MS dev tools allow any combinations of shared/static link, why libtool 
>>>> give worse possible options?
>>>  I think you should be cleaning house, instead of allowing random bits
>>>  and bobs to connect together. The real problem is that you have 4
>>>  incompatible versions of zlib1.dll in the first place.
>>  Of course cleaning is required, but it's not always possible to simple 
>> rebuild some particular lib on Win32.
>>  But I was talking about ability to link static in shared.
> This is relevant, it is what kicked off the discussion. How about a
> tighter reign over what gets contributed instead of randomly accepting
> executable code?
Thanks for idea. Do you always have enough volunteers to get all tasks done? :)

>>>  Libtool is good at preventing multiple exports on win32, I have seen
>>>  disasters where zlib is exported *multiple* times in different DLLs of
>>>  the same project because the author does not know what is going on. At
>>>  least it was a compatible and same version of zlib.
>>  Right, it's nice idea to prevent static link for shared lib that blindly 
>> use "--export-all-symbols". But for well-designed libs that use dllexport 
>> attribute or def-file disallowing static libs is just obstacle.
> You have to remember, using static libs with shared DLLs in itself is a
> bad idea, you still end up with *multiple* instance of it at runtime as
> well, even if it is not exported, moving the problem from link time to
> run time.
Win32 dll processing is good designed. You will never have any problem at 
runtime with multiple functions with same name from different modules. They are 
isolated, just like local static variables.

> Above all, --export-all-symbols is default behavior in the absents of
> any dllexport attributes or def files, so yes, blocking static libraries
> is justified without introducing PE specific scanning rules.
Unfortunately ld currently do not support "--no-export-all-symbols" (but 
dlltool does support).
So I need to patch ld first. Don't think that special case dll-building with 
dlltool will be accepted for libtool code. :)

>>  Ok, I got the advantage of libtool, but still don't understand why this 
>> should prevent linking static libs in well-designed shared lib?
> Your best option is either go entirely static or DLLs only. Going
> somewhere in between is just plain trouble on Windows.
What's the trouble?
If you don't blindly use "--export-all-symbols" (either implicitly or 
explicitly) you will never have any trouble on win32.

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

Re: -no-undefined on Win32

[Evgeny Grin]

29.04.2014, 05:59, "Bob Friesenhahn" :
> On Mon, 28 Apr 2014, Evgeny Grin wrote:
>>  Good. But requiring "-no-undefined" for Win32 flag lower probability of 
>> successful compile.
> In what way does it lower the probability of a successful compile?
> Static linkage is much more portable than dynamic.
That was another asked question: why libtool didn't fail if requested dynamic 
lib was not build.
Anyway, if I'm building dynamic lib and it was not built, that's called 
"unsuccessful build".

> The situation you outlined is due to a defective package
> preparation/build environment.  A proper build has just one version of
> a given library in a link.
Could you explain this a little bit?
In the topic "-no-undefined on Win32" I was talking about only one version of 
lib.

> Regardless, it is very unlikely that libtool will react to your plea
> (if it does at all) in a timely fashion and so you are best advised to
> fix your build without relying on significant changes in libtool.
All my builds were "fixed" already.
I'd like to improve libtool.
If *uncommenting* one line and deleting other line in libtool are significant 
changes, then I'd like to significantly change libtool. :)

Could you answer my main question: why libtool don't follow logic of other GNU 
tools? Instead of acting as a "tool" and passing required flags to 
compiler/linker, libtool is acting as mentor and does not do it work until you 
signal that you aware of something?

-- 
Best Wishes,
Evgeny Grin

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

Re: -no-undefined on Win32

[Evgeny Grin]

29.04.2014, 11:36, "Peter Rosin" :
> Here you have a point, methinks. If you have specified -disable-static, it
> is surprising that static can be the only output, instead of a fail.
Correct. But this is another topic, which I raised already in this mailing list.

>>>  The situation you outlined is due to a defective package
>>>  preparation/build environment.  A proper build has just one version of
>>>  a given library in a link.
>>  Could you explain this a little bit?
> It is defective since the project has failed to specify -no-undefined when
> it proceeds with a link without undefined symbols. Just add the dang flag
> and be done with. Yes, I did read the argument that some projects decide to
> special-case adding -no-undefined only for systems that must have it to 
> produce
> shared libs, or refuses to add it outright, but that's just plain silly. If
> someone doesn't want to support weird systems/tools, why not use $CC -shared
> directly and erase Libtool from the project instead? Seriously!
So again we return to first question.
What's advantage of requiring "-no-undefined" flag on win32?
If code is designed well for win32 then compiler/linker can create shared lib. 
No advantage of using "-no-undefined" as lib will not use undefined symbols in 
any way.
If code is not designed for win32 then compiler/linker will fail to create 
shared lib. No advantage of using "-no-undefined".

For linux systems I see advantages of "-no-undefined": to force produced lib to 
have all symbols defined (or fail) and to check that all symbols are defined 
for lightweight emulation of win32 behavior.
But for win32 "-no-undefined" flag must be used automatically as real checks 
for undefined symbols will be done by linker anyway.


>>>  Regardless, it is very unlikely that libtool will react to your plea
>>>  (if it does at all) in a timely fashion and so you are best advised to
>>>  fix your build without relying on significant changes in libtool.
>>  All my builds were "fixed" already.
>>  I'd like to improve libtool.
>>  If *uncommenting* one line and deleting other line in libtool are 
>> significant changes, then I'd like to significantly change libtool. :)
> You have "forgotten" the needed testsuite changes involved which should verify
> the new behavior. Those would probably be more significant than a couple of
> one-liners. You're also ignoring the impact on projects relying on the current
> behavior, how do you propose to handle them? A new flag? Named what? 
> -undefined?
> -no-no-undefined? -has-undefined? -undefined-symbols?
I'm a volunteer. :)
I'm not suggesting to delete or change "-no-undefined" flag. All projects that 
have this flag will continue to function as before.
But new projects can skip unnecessary step, unless they want to have no 
undefined symbols on Linux/other platforms - in this case "-no-undefined" can 
be used as before.

>>  Could you answer my main question: why libtool don't follow logic of other 
>> GNU tools? Instead of acting as a "tool" and passing required flags to 
>> compiler/linker, libtool is acting as mentor and does not do it work until 
>> you signal that you aware of something?
> Because the current behavior results in a working library in more cases?
Currently you have to properly write code AND specify "-no-undefined" for 
win32. 
So current behavior results in working library in less cases as specifying 
"-no-undefined" without correct code will not result in working library.

> Because it breaks projects depending on current behavior?
I'm not suggesting to remove this option, so projects depending on current 
behavior will continue to work as before. Only will fail in less cases. :)

> Or are you mainly referring to your desire to link static libs into a
> shared lib? 
No, it was another topic that was already discussed.

Thanks for constructive answers!

-- 
Best Wishes,
Evgeny Grin

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

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

iQEcBAEBCAAGBQJWu4/0AAoJEL96xKXqwrr0t40H/RaZsW/fRlpDJYmBkmGtPxIG
ns9EqlJh+ZnWTO0BGe3EI9qymqiFcznT0nRqe6j9NrFoFn6fYDUM2bpUrGuck+Yx
uIqFDRdMq1m936QA/IW/O/H4MjwdbzJEEDW/kAxlDD5Fdr/9DCkLZ7e9QrAHBYnl
fyb3MWIkmidY5dzv/TFse/NnBIKX937HOCtdoMbOxyZuotpTixHBn1MX1yzOvMI/
DCGLiEIHRMQ07b8xwUfO0JoJiUbJdR6P7pOBYz5i/6eLMCPXe7j33m4yc6UqUs7F
yRyKywrCvG8EmUo4IU5JKb4s0woq4I7Tsl4EvXq6as1h5r7yvsn9kTXNlgf+224=
=ycKd
-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

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

[Evgeny Grin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11.02.2016 2: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.
OK. So porting something to AIX will result in conditional
"-no-undefined" for AIX too. But again, why we need to signal this for
libtool on W32? Is it required only for automatic fallback to static
instead of shared?

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

On W32 this looks like "-no-missing-headers" for precompile/compile
mode. Linker will fail anyway if some symbol is not resolved.

Is it required for automatic fallback to static? Even if so, isn't it
better to try to link at first and fallback to static only if linker failed?
I'm not talking currently about reasonability of such fallback.

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

iQEcBAEBCAAGBQJWvGgAAAoJEL96xKXqwrr0MbwIAMGM7TcWamoel1hG/aAXiz//
ImZRpcw4cwRpmJnh0j7V3Zw8nkpoaMZcXRSmql+7xlDpLu++Scv55TTFckKcYU8V
90GlqtmcbHLsU4DGyqtwlEG0ah4kopsQUrQlfyZ2+LiSx/8a7yiEn/5YOQRmMsOU
wN7f2Va2m2HTesMG+E2rNzrEMVyWaiRII62sjLXvVXDyap3/7LENybC69ru3LkrE
Qkq9l3e61aci0/pES13Y/lmylPzYMoQYDbGkthdnLWKa+W3Byt9hRKeGr+SyCXX6
r8r0saBnQp5H57Ma5IAKFNAMIMVPbb7SRJM2LEa/uUQ4eDe1aOVl4bvLIzXPTRU=
=84n8
-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 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

[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

[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

[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 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", "-

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

[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

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

[Evgeny Grin]

Follow-up Comment #1, sr #110901 (project libtool):

[(Ошибка - не найдено)]
No, it's wrong.
See https://sourceware.org/pipermail/cygwin/2021-June/248814.html


___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

[sr #110901] libtool hangs indefinitely on windows when used in msys due to cmd.exe call bug

[Evgeny Grin]

Follow-up Comment #2, sr #110901 (project libtool):

[(Ошибка - не найдено)]
When starting any program under MSYS (and MSYS2), the MSYS[2] checks whether
the lunched program is linked with msys-*.dll. 
If program is linked with this DLL then the program expects POSIX-like
environment so no path translation is performed.
If program is not linked with this DLL then the program is native Windows
binary, which expects native Windows paths. In such case the MSYS[2] scans all
arguments for POSIX-like paths and converts all of them to Windows native
paths. The problem is that all Windows drives are mounted as single letter in
the root so the path like "/d/path/file" should be translated into
"D:/path/file", while "/c" is translated into "C:/"
To prevent this translation double slash could be used. Double slash is
replaced with single slash.

Examples:


MSYS ~
$ cmd /c echo "/c"
Microsoft Windows [Version 10.0.19045.3208]
(c) Microsoft Corporation. All rights reserved.

C:\msys64\home\user>exit

MSYS ~
$ cmd //c echo "/c"
C:/

MSYS ~
$ cmd //c echo "//c"
/c

MSYS ~
$ cmd //c echo "///c"
//c

MSYS ~
$ echo.exe "/c"
/c

MSYS ~
$ echo.exe "//c"
//c

"echo.exe" is Msys program. cmd is not Msys program.


___

Reply to this item at:

  

___
Сообщение отправлено по Savannah
https://savannah.gnu.org/

Re: libtool hangs in func_convert_core_msys_to_w32 when cross-compiling with mingw under cygwin

[Evgeny Grin]

Sorry for necroreply.

When *cross* compiling from Cygwin to MinGW (read: native Windows) the 
different "--build" and "--host" must be used, like

--build=x86_64-pc-cygwin --host=x86_64-w64-mingw32
or
--build=x86_64-pc-cygwin --host=x86_64-pc-mingw64
as you are building is on Cygwin, not on MinGW.

--
Evgeny

On 25.06.2021 18:07, Dietmar May wrote:

SUMMARY

func_convert_core_msys_to_w32 in

/usr/share/libtool/build-aux/ltmain.sh

has an extraneous '/' in the call to

( cmd //c echo "$1" )

causing make to hang indefinitely

when configured with

--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32


The project builds successfully on msys2 + mingw-w64-x86_64-gcc.

msys2 has the same issue ('//c'), but the compiler is in the path, so no
cross-compilation configuration is needed (and apparently this function
is not invoked).


DETAILS

func_convert_core_msys_to_w32() in the generated libtool script, when
configured using --build and --host for mingw, expands to:

cmd //c echo ... | sed

//c is not a valid option to cmd.exe, and causes cmd.exe to hang
indefinitely. This is reproducible from the command line:

cmd //c echo .libs/ | /usr/bin/sed -e 's/[ ]*$//' -e 
's|*|\\|g;s|/|\\|g;s|\\||g'

ps aux shows cmd.exe, with sed at pid cmd.exe + 1. kill is the only way
to terminate.

By changing "cmd //c" to "cmd /c", the command completes successfully.


/usr/share/libtool/build-aux/ltmain.sh is the template, which contains
the code:

# func_convert_core_msys_to_w32 ARG
# Convert file name or path ARG from MSYS format to w32 format. Return
# result in func_convert_core_msys_to_w32_result.
func_convert_core_msys_to_w32 ()
{
    $debug_cmd

    # awkward: cmd appends spaces to result
    func_convert_core_msys_to_w32_result=`( cmd //c echo "$1" ) 2>/dev/null` |
      $SED -e 's/[ ]*$//' -e "$sed_naive_backslashify"`
}
#end: func_convert_core_msys_to_w32

I've been able to get past this problem by editing this file and running
configure again.

Unfortunately, make aborts at a later point with a different (but
perhaps related?) error:

func_to_tool_file src/.libs/libopenocd.libcmd

func_convert_file_msys_to_w32 src/.libs/libopenocd.libcmd
func_convert_core_msys_to_w32 src/.libs/libopenocd.libcmd
func_convert_file_check src/.libs/libopenocd.libcmd
src\\.libs\\libopenocd.libcmd
func_execute_cmds $AR $AR_FLAGS $oldlib$oldobjs~$RANLIB $tool_oldlib exit $?
   exit $?w_eval x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a
@src\\.libs\\libopenocd.libcmd
func_quote_for_expand x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a
@src\\.libs\\libopenocd.libcmd
func_notquiet x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a
@src\\.libs\\libopenocd.libcmd
func_echo x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a
@src\\.libs\\libopenocd.libcmd


libtool: link: x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd

:/No such file or directory\.libs\libopenocd.libcmd /make[2]: *** 
[Makefile:2811: src/libopenocd.la] Error 1

The file *is* there:

$ ls src/.libs
libopenocd.lax  libopenocd.libcmd

Running the command directly completes with no errors:

$ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a 
@src\\.libs\\libopenocd.libcmd
$


I don't understand *why libtool is converting paths to windows format*
in order to run inside of a cygwin shell? The command completes successfully
*if no path conversion occurs* - so why bother?

$ x86_64-w64-mingw32-ar cru src/.libs/libopenocd.a @src/.libs/libopenocd.libcmd

$

Is this a holdover from 13 year old mingw behavior? or related somehow
to running autotools in a cmd.exe environment (like Microsoft's original
NT "posix" subsystem, a port of gnu commands to run "natively" under
cmd.exe)?

Can libtool just ditch all of the back and forth path conversions, and
simplify all of this?


REPRODUCING

Install mingw64-x86_64-gcc-g++, autoconf, autoconf2.1, autoconf2.5,
automake and pkg-config in cygwin (along with make and git).

I believe that will pull in all required dependencies.


git clonehttps://git.code.sf.net/p/openocd/code  


cd openocd

./bootstrap

./configure --disable-werror --disable-doxygen-pdf --enable-ftdi
--enable-jlink --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32

make # or make -j8




OpenPGP_0x460A317C3326D2AE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature