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

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

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

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 tra

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

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

Re: MSW DLLs support in libtool

ck 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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

d 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" unc

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

icitly 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+ bzZ

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

re 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

Re: MSW DLLs support in libtool

4, 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 SIGNA

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

Re: -no-undefined on Win32

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

Re: -no-undefined on Win32

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

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

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

Re: -no-undefined on Win32

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 somethi

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

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 zl

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

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 somet

Re: -no-undefined on Win32

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

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

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

Passing flags with mode=link

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

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

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

-no-undefined on Win32

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

Forced static lib if any depend lib is static on win32

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"