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 >> "-w32-aix-shared-compatible". And

Re: MSW DLLs support in libtool

-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

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". With that logic >> "make" will

Re: MSW DLLs support in libtool

On 2/12/16, Evgeny Grin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 12.02.2016 0:14, Nick Bowler wrote: >> On 2/11/16, Evgeny Grin wrote: >>> * change default shared lib mode from "on" to "auto" or "try" and fail >>> if shared lib cannot be

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 --no-undefined. I.e. If you

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

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, shared libraries. >> This

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 installed on the system (by

Re: MSW DLLs support in libtool

Peter Rosin lysator.liu.se> writes: > On 2016-02-11 00:38, Bob Friesenhahn wrote: > > > > Also, "-no-undefined" does not indicate if the library has undefined > > symbols (many DLLs have undefined symbols). Sorry but this is just completely incorrect as written. It's very probable that you

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

Simon Richter hogyros.de> writes: > On 10.02.2016 17:49, Vadim Zeitlin wrote: > > > *** Warning: Trying to link with static lib archive /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a. > > *** I have the capability to make that library automatically link in when > > *** you link to this

Re: MSW DLLs support in libtool

On 2016-02-12 22:12, Vadim Zeitlin wrote: > Several concrete questions in this thread asking for any benefits of the > current libtool behaviour went unanswered, but let me try once again > nevertheless: do you see any useful consequences of performing the check > for PIC when targeting Windows

Re: MSW DLLs support in libtool

On 2016-02-12 21:59, Vadim Zeitlin wrote: > Peter Rosin writes: >> On 2016-02-11 00:38, Bob Friesenhahn wrote: >>> It indicates that the build configuration has agreed to supply any >>> additional dependency libraries if there otherwise would be undefined >>> symbols. >> >> Well said, I would

Re: MSW DLLs support in libtool

On 2016-02-11 00:38, Bob Friesenhahn wrote: > On Wed, 10 Feb 2016, Evgeny Grin wrote: >> >> As result - "-no-undefined" is used only on W32 without any practical >> benefit: if lib have some undefined symbols, it will not be build on W32 >> as shared lib regardless of "-no-undefined" flag. And

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

On Thu, 11 Feb 2016, Evgeny Grin wrote: Repeat once more: with OS-specific code parts you can't add "-no-undefined" unconditionally. GraphicsMagick (which compiles on a wide variety of systems, including Windows and AIX) has been specifying -no-undefined as a standard option (used on any

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

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

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

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

Re: MSW DLLs support in libtool

Hi, On 10.02.2016 17:49, Vadim Zeitlin wrote: > *** Warning: Trying to link with static lib archive > /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you

Re: MSW DLLs support in libtool

-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

Re: MSW DLLs support in libtool

-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

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

Re: MSW DLLs support in libtool

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

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

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

Re: MSW DLLs support in libtool

Hi! [Replying to various things across the thread] On 2016-02-10 04:53, Vadim Zeitlin wrote: > On Tue, 9 Feb 2016 21:29:23 -0600 (CST) Bob Friesenhahn > wrote: > > BF> On Wed, 10 Feb 2016, Vadim Zeitlin wrote: > BF> > > BF> > Sorry but this is just not true for

Re: MSW DLLs support in libtool

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

Re: MSW DLLs support in libtool

On 2/9/16, Vadim Zeitlin wrote: > I'd like to create Windows binaries for my software from Linux, which > includes creating a couple of DLLs and EXEs that use them. This is not too > difficult to do with just manual makefiles as both the cross-compiler and > linker work

Re: MSW DLLs support in libtool

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