-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 versio
-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
On Sat, 13 Feb 2016 00:38:48 +0100 Peter Rosin wrote:
PR> On 2016-02-12 21:59, Vadim Zeitlin wrote:
PR> > Peter Rosin writes:
PR> >> On 2016-02-11 00:38, Bob Friesenhahn wrote:
PR> >>> It indicates that the build configuration has agreed to supply any
PR> >>> additional dependency libraries if th
On Sat, 13 Feb 2016 00:38:15 +0100 Peter Rosin wrote:
PR> On 2016-02-12 22:12, Vadim Zeitlin wrote:
PR> > Several concrete questions in this thread asking for any benefits of the
PR> > current libtool behaviour went unanswered, but let me try once again
PR> > nevertheless: do you see any useful
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 als
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
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 libr
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 mea
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
-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)...
>
-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=
-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 ad
-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
On 2/12/16, Evgeny Grin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12.02.2016 0:14, Nick Bowler wrote:
>> On 2/11/16, Evgeny Grin wrote:
>>> * change default shared lib mode from "on" to "auto" or "try" and fail
>>> if shared lib cannot be created when mode is "on". With th
-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
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
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 opt
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 - i
-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
On Thu, 11 Feb 2016, Evgeny Grin wrote:
Repeat once more: with OS-specific code parts you can't add
"-no-undefined" unconditionally.
GraphicsMagick (which compiles on a wide variety of systems, including
Windows and AIX) has been specifying -no-undefined as a standard
option (used on any OS)
-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 at
-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
-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
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 co
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 actu
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 ha
-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
-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
-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
>>
-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
-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
-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 wor
-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
-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
-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 t
On Wed, 10 Feb 2016 11:02:29 -0500 Nick Bowler wrote:
NB> On 2/10/16, Vadim Zeitlin wrote:
NB> > On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler wrote:
NB> > NB> On 2/10/16, Bob Friesenhahn wrote:
NB> > NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
NB> > NB> >> I agree wholeheartedly with the n
On 2/10/16, Vadim Zeitlin wrote:
> On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler wrote:
> NB> On 2/10/16, Bob Friesenhahn wrote:
> NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
> NB> >> I agree wholeheartedly with the notion that --disable-static
> NB> >> should end up in a failure and not some
On Wed, 10 Feb 2016 10:51:02 -0500 Nick Bowler wrote:
NB> The default (on all platforms) is to create both static libraries and,
NB> when possible, shared libraries.
This is not unreasonable (although not obviously the right thing to do
neither IMO), but I'm only speaking, since the beginning o
On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler wrote:
NB> On 2/10/16, Bob Friesenhahn wrote:
NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
NB> >> I agree wholeheartedly with the notion that --disable-static should end
NB> >> up in a failure and not somehow degrade to a static build anyway. I
NB>
On 2/10/16, Vadim Zeitlin wrote:
> On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler wrote:
> NB> On 2/9/16, Vadim Zeitlin wrote:
> NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler
> NB> > wrote:
> NB> > NB> Here's the thing. Libtool is, by default, designed to
> NB> > NB> transparently suppor
On 2/10/16, Peter Rosin wrote:
> Personally, I don't get why the win32 option exist at all. I see no
> reason to discriminate against Windows like that. Make the no-windows-
> purists opt out with no-win32 (or whatever) instead.
What does the win32-dll option actually do? I just learned about i
On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler wrote:
NB> On 2/9/16, Vadim Zeitlin wrote:
NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler wrote:
NB> > NB> Here's the thing. Libtool is, by default, designed to transparently
NB> > NB> support the case where building a shared library is not p
On 2/10/16, Bob Friesenhahn wrote:
> On Wed, 10 Feb 2016, Peter Rosin wrote:
>> I agree wholeheartedly with the notion that --disable-static should end
>> up in a failure and not somehow degrade to a static build anyway. I
>
> Is this not the case? I have seen builds on Windows fail due to using
On 2/9/16, Vadim Zeitlin wrote:
> On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler wrote:
> NB> Here's the thing. Libtool is, by default, designed to transparently
> NB> support the case where building a shared library is not possible.
>
> This is, IMO, an obsolete principle to follow. I admit it m
On Wed, 10 Feb 2016, Peter Rosin wrote:
As for your point about non-trivial programs not working without
special treatment, there are a large body of packages that build just
fine using Cygwin on-top of Windows, without much in the way of special
treatment. Cygwin also suffers the from the curse
On Wed, 10 Feb 2016 10:02:25 +0100 Peter Rosin wrote:
PR> You appear confused (as almost everybody else) about what -no-undefined
PR> means to libtool. The confusion stems from(?) the similarly named linker
PR> option, --no-undefined, which apparently does what people expect from
PR> the 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 the MSW DLLs. If the libtool use
On Tue, 9 Feb 2016 21:29:23 -0600 (CST) Bob Friesenhahn
wrote:
BF> On Wed, 10 Feb 2016, Vadim Zeitlin wrote:
BF> >
BF> > Sorry but this is just not true for the MSW DLLs. If the libtool user
BF> > tries to build a DLL, you can safely assume that it will not have
undefined
BF> > symbols. Anythin
On Tue, 9 Feb 2016 21:18:42 -0600 (CST) Bob Friesenhahn
wrote:
BF> On Tue, 9 Feb 2016, Vadim Zeitlin wrote:
BF> >
BF> > 2. Enabling this option is not enough as you must also painstakingly add
BF> > -no-undefined to all LDFLAGS. Why does libtool need to force you to do
BF> > it instead of ju
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 di
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 r
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 undef
On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler wrote:
NB> On 2/9/16, Vadim Zeitlin wrote:
NB> > I'd like to create Windows binaries for my software from Linux, which
NB> > includes creating a couple of DLLs and EXEs that use them. This is not too
NB> > difficult to do with just manual makefiles a
On 2/9/16, Vadim Zeitlin wrote:
> I'd like to create Windows binaries for my software from Linux, which
> includes creating a couple of DLLs and EXEs that use them. This is not too
> difficult to do with just manual makefiles as both the cross-compiler and
> linker work just fine. Libtool is anoth
Hello,
I'd like to create Windows binaries for my software from Linux, which
includes creating a couple of DLLs and EXEs that use them. This is not too
difficult to do with just manual makefiles as both the cross-compiler and
linker work just fine. Libtool is another matter entirely however:
1.
55 matches
Mail list logo