as undefined
> symbols (many DLLs have undefined symbols). It indicates that the build
> configuration has agreed to supply any additional dependency libraries
> if there otherwise would be undefined symbols.
Well said, I would also like to add that libtool -no-undefined *does* *not*
imply ld -
__
https://lists.gnu.org/mailman/listinfo/libtool
uot;win32 only", but creating a special mode for that would make no sense,
because then the source would no longer be portable and we wouldn't need
libtool. The extra hoops for creating Windows DLLs are due to additional
constraints on the source code, but this would be relaxing a constr
k=
=iUv9
-END PGP SIGNATURE-
___
https://lists.gnu.org/mailman/listinfo/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 ne
-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
-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
-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 fo
-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 experienc
-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 fo
-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
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 Libt
n Windows fail due to
NB> > NB> > using --disable-static.
NB> > NB>
NB> > NB> I just tested it on a library which does not specify -no-undefined,
NB> > NB> and therefore won't be built as a shared lib on Windows:
NB> >
NB> > This just doesn&
y which does not specify -no-undefined,
> NB> and therefore won't be built as a shared lib on Windows:
>
> This just doesn't correspond to my experience: when cross compiling from
> Linux using libtool 2.4.2, a static library is created.
I cannot reproduce it. The build
e beginning of this thread,
about the behaviour in LT_INIT(disable-static) case.
NB> If you explicitly request a shared library (i.e., call libtool in
NB> link mode with the -shared option), and it is not possible, you should
NB> receive an error. If this is not happening, then this is p
dows:
This just doesn't correspond to my experience: when cross compiling from
Linux using libtool 2.4.2, a static library is created. If you want to
reproduce this, just clone https://github.com/vadz/test-libtool-dll and
then do
% libtoolize
% automake --add-missing --f
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 de
not generally needed, so maybe this is why it works anyway.
Regards,
Nick
___
https://lists.gnu.org/mailman/listinfo/libtool
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
ows fail due to using
> --disable-static.
I just tested it on a library which does not specify -no-undefined, and
therefore won't be built as a shared lib on Windows:
./configure
[...]
libtool: warning: undefined symbols not allowed in i486-pc-mingw32
shared libraries; buildi
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 princ
MinGW.
I agree wholeheartedly with the notion that --disable-static should end
up in a failure and not somehow degrade to a static build anyway. I
Is this not the case? I have seen builds on Windows fail due to using
--disable-static.
Libtool is not well optimized for Windows or even GNU Linux
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>
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
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
un
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
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, th
using regressions.
This is not really true. For example, the linker on GNU Linux
implicility supplies libraries at link time (because of how they were
built) and libtool has no way to know about library dependencies which
are not listed in .la files.
Some GNU Linux distributions intentio
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
with just manual makefiles as both the cross-compiler and
NB> > linker work just fine. Libtool is another matter entirely however:
NB> >
NB> > 1. By default, libtool silently doesn't create DLLs at all and
NB> >"win32-dll" LT_INIT() option needs to be used j
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
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 howeve
On Fri, 5 Feb 2016, Harald Servat wrote:
I'm unsure on how to interpret the libtool related information because it is
very simplistic
configure:11699: checking if libtool supports shared libraries
configure:11701: result: no
however, at some point earlier, the following test mig
On 2016-02-03 14:30, Harald Servat wrote:
On 02/02/2016 07:02 PM, Mike Frysinger wrote:
On 02 Feb 2016 17:51, Harald Servat wrote:
we want to use libtool on a system on which we have to cross-compile
from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx).
Unfortunately, I&#
... cross
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... no
However, the system support suggested to add the flag -Xg into the
Fujitsu compiler and we found that the following configure did work.
./configure --prefix=/tmp/test CC=fccpx
a program can dlopen itself... cross
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... no
>
>However, the system support suggested to add the flag -Xg into the
> Fujitsu compiler and we found that the following configur
On 02/02/2016 07:02 PM, Mike Frysinger wrote:
On 02 Feb 2016 17:51, Harald Servat wrote:
we want to use libtool on a system on which we have to cross-compile
from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx).
Unfortunately, I'm unable to get libtool (version 2.4.
On 02 Feb 2016 17:51, Harald Servat wrote:
>we want to use libtool on a system on which we have to cross-compile
> from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx).
> Unfortunately, I'm unable to get libtool (version 2.4.2) to generate
> shared librarie
Hello list,
we want to use libtool on a system on which we have to cross-compile
from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx).
Unfortunately, I'm unable to get libtool (version 2.4.2) to generate
shared libraries.
I have written a very small libtool + auto
Hi Michael :)
On 20-Jan-16 10:18, Michael Haubenwallner wrote:
Hi Michael,
On 01/19/2016 09:44 PM, Michael Felt wrote:
L.S.,
If I understand the documentation correctly libtool places non-shareable
members (.o files) in the src directory
and "shareable aka PIC objects in src/.libs"
Hi Michael,
On 01/19/2016 09:44 PM, Michael Felt wrote:
> L.S.,
>
> If I understand the documentation correctly libtool places non-shareable
> members (.o files) in the src directory
> and "shareable aka PIC objects in src/.libs". However, libtool makes only one
>
L.S.,
If I understand the documentation correctly libtool places non-shareable
members (.o files) in the src directory
and "shareable aka PIC objects in src/.libs". However, libtool makes
only one size of objects - either 32-bit or 64-bit.
As "aixtools" I am tryin
Ping ?
On Sun, 2015-10-18 at 15:41 +0200, Joakim Tjernlund wrote:
> While googling for a fix for bug#21455,
> http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html ,
> I came across:
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/
While googling for a fix for bug#21455,
http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html ,
I came across:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/use-sysroot-in-libpath.patch?id=release-2010.12
This appear to be the correct fix
Hi Robert,
Thanks for the response, both here and on stack overflow. That sounds right
I’ll give it a try.
Regards,
Jacob
> On Oct 6, 2015, at 2:49 PM, Robert Boehne wrote:
>
> Because Libtool was not used to create libB.dylib, it does not know how to
> adjust the environmen
Because Libtool was not used to create libB.dylib, it does not know how to
adjust the environment to find it. You have to do that.
You can put the path to libB in your environment, or you can add a flag to
hard-code that path when libA.la is used.
Do that by adding an RPATH specification like
Hello,
Am stumped on a link. Even after pouring over the manuals for hours and
searching online it is probably a misunderstanding of autotools.
I have one .la library made by libtool, one .dylib shared library and am
creating a program. The .la is linked to the .dylib and the program uses the
; While we are on it, merge the macro-"blacklist" with similar list
> > implemented in gettext, except the 'm4_esyscmd'. It's kept
>
> s/except the/except for/
>
> > defined because we already trace AC_INIT macro for package
> > version, while it is of
ato wrote:
> > This configure.ac is extreme slow on libtool-2.4.6.
> > But It run smoothly on libtool-2.4.2.
> > https://github.com/groonga/groonga/blob/master/configure.ac
>
> thanks for reproducer!
>
> This _really_ looks like issue mentioned [1], though the thread is
> be
r list
> implemented in gettext, except the 'm4_esyscmd'. It's kept
s/except the/except for/
> defined because we already trace AC_INIT macro for package
> version, while it is often specified by
> m4_esyscmd(git-version-gen). Similarly to m4_include, m4_esyscmd
> migh
Hi Eric, thanks for your review!
On Saturday 19 of September 2015 15:05:07 Eric Blake wrote:
> On 09/19/2015 02:09 AM, Pavel Raiskup wrote:
> > Hi Hiroyuki Sato,
> >
> > On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote:
> >> This configure.ac is
On 09/19/2015 02:09 AM, Pavel Raiskup wrote:
> Hi Hiroyuki Sato,
>
> On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote:
>> This configure.ac is extreme slow on libtool-2.4.6.
>> But It run smoothly on libtool-2.4.2.
>> https://github.com/groonga/groon
Hi Hiroyuki Sato,
On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote:
> This configure.ac is extreme slow on libtool-2.4.6.
> But It run smoothly on libtool-2.4.2.
> https://github.com/groonga/groonga/blob/master/configure.ac
thanks for reproducer!
This _really_ looks l
making mention that using
"-nostdlib" has adverse side effects with pthreads. I'm using a library,
log4cplus, which does make use of pthreads.
Using "./configure --help" doesn't reveal any method of making libtool discontinue the
use of "-nostdlib". Ho
adverse side effects with pthreads. I'm
using a library, log4cplus, which does make use of pthreads.
Using "./configure --help" doesn't reveal any method of making libtool
discontinue the use of "-nostdlib". How do I make this happen?
Andy
__
me distros, such as Ubuntu, will completely drop the
dependency on the library. The workaround is well known: use
-Wl,--no-as-needed.
Unfortunately, libtool moves the options around, and since
-Wl,--(no-)?-as-needed applies to the libraries that are _after_ it, the result
is disastrous:
# ./lib
Hello.
This configure.ac is extreme slow on libtool-2.4.6.
But It run smoothly on libtool-2.4.2.
https://github.com/groonga/groonga/blob/master/configure.ac
Could you tell me how to fix this problem?.
Is this libtool's Bug?
* OS OSX 10.10.5. and CentOS7
Thanks.
libtool-2.4.6
time
Hi Nichols,
On 2015-08-07 17:49, Nichols A. Romero wrote:
Hi,
Has libtool been ported to Blue Gene/Q?
it has been ported to BG/L in 2009, search ChangeLog for BlueGene. This
port detects bgxl*, bgf*, mpixl* compilers and works for me on BG/P and
BG/Q. I explicitly force static linking and
I originally asked this question on stackoverflow. Some of them recommended
me that I ask it on this address, since it looks very libtool specific.
I actually solved my problem by downloading pre-built binaries but I ask to
you since maybe there is a bug or something.
My original question
<h
Hi,
Has libtool been ported to Blue Gene/Q?
I have had trouble getting it to behave properly and have had to resort to
hacking it. Some of the issues include:
- It is trying to link in shared libraries, even though --enable-static
--disable-shared has been specified in autoconf
- Libtools all
Libtool currently does not properly detect ELF Tool Chain's strip(1),
and thus does not invoke strip when ELF Tool Chain is in use.
Originally reported in FreeBSD here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198611
Xin Li posted a patch in Savannah to address it:
savannah.gnu.org/
Has anyone had a chance to look this patch over?
`~Eric
On 04/14/2015 12:46 PM, Eric Bavier wrote:
I'd like to get some additional feedback on this patch for the Cray
Compiler Environment support in libtool, now that the copyright
assignment process has (finally) gone through.
0001-li
ork
for the other architecture was installed on the system.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Wed, 13 May 2015, Lane wrote:
>
>> arm-blues-linux-gnueabi-libtool: install: chmod 644
>> /opt/blues/lib/libbl_parsers.a
>> arm-blues-linux-gnueabi-libtool: install: arm-blues-linux-gnueabi-ranlib
>&g
On Wed, 13 May 2015, Lane wrote:
arm-blues-linux-gnueabi-libtool: install: chmod 644
/opt/blues/lib/libbl_parsers.a
arm-blues-linux-gnueabi-libtool: install: arm-blues-linux-gnueabi-ranlib
/opt/blues/lib/libbl_parsers.a
../../../arm-blues-linux-gnueabi-libtool: line 1104:
arm-blues-linux
I hope this is the right list to ask for libtool help. If not, please
let me know.
I have an app that uses autotools and it works just fine on x86_64.
However, when cross-compiling for arm, I am able to configure, make
(successfully), but then make install is a problem and I was
Hello,
Bug #18325 has been reported 8 months ago with no reply from Libtool
authors: http://lists.gnu.org/archive/html/bug-libtool/2014-08/msg2.html
Can someone please take position on a possible resolution?
Regards,
Gregory
___
https
I'd like to get some additional feedback on this patch for the Cray
Compiler Environment support in libtool, now that the copyright
assignment process has (finally) gone through.
>From 533d9854c7b3c6c351f5a8d7f2f69e69fb73ad40 Mon Sep 17 00:00:00 2001
From: Eric Bavier
Date: Tue, 18 Nov
> -Original Message-
> From: Bob Friesenhahn [mailto:bfrie...@simple.dallas.tx.us]
> Sent: Tuesday, April 07, 2015 7:26 AM
> To: Andy Falanga (afalanga)
> Cc: libtool@gnu.org
> Subject: Re: libtool is not wanting to play nicely with cross compiler
>
> On Mon,
ns to
cross-compilation.
How are your cross-tools named? Tool naming is important.
What are the arguments that you passed to configure?
I've finally gotten my configure script to complete and was running
the main compilation when I ran into this error:
libtool: link: warning:
`/sr
into this error:
libtool: link: warning:
`/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems
to be moved
libtool: link: warning:
`/src/afalanga/crisscross/tmp/sysroots/zc706-zynq7/usr/lib/libstdc++.la' seems
to be moved
libtool: link: warning:
`/src/afa
[Adding Automake]
On 2015-03-23 16:00 +, Gary V. Vaughan wrote:
> > On Mar 23, 2015, at 2:42 PM, Bob Friesenhahn
> > wrote:
> > > On Mon, 23 Mar 2015, Christian Rössel wrote:
[...]
> > > I discovered some files in
> > > http://ftpmirror.gnu.or
> On Mar 23, 2015, at 2:42 PM, Bob Friesenhahn
> wrote:
>> On Mon, 23 Mar 2015, Christian Rössel wrote:
>>
>> Dear Gary,
>>
>> thanks for libtool-2.4.6!
>>
>> I discovered some files in
>> http://ftpmirror.gnu.org/libtool/libtool-2.4.6
On Mon, 23 Mar 2015, Christian Rössel wrote:
Dear Gary,
thanks for libtool-2.4.6!
I discovered some files in
http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz that IMO don't belong
there. The filenames start with "._" (just do a 'find . -name "._*"'
Dear Gary,
thanks for libtool-2.4.6!
I discovered some files in
http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz that IMO don't
belong there. The filenames start with "._" (just do a 'find . -name
"._*"') and seem to contain dropbox meta data.
Che
Follow-up Comment #11, sr #108558 (project libtool):
Don't you want to close this bug?
___
Reply to this item at:
<http://savannah.gnu.org/support/?108558>
___
Message sent via/
Follow-up Comment #4, sr #108559 (project libtool):
Care to close this bug?
___
Reply to this item at:
<http://savannah.gnu.org/support/?108559>
___
Message sent via/by Savannah
> -Original Message-
> From: Peter Johansson [mailto:troj...@gmail.com]
> Sent: Thursday, March 05, 2015 6:46 PM
> To: Andy Falanga (afalanga); libtool@gnu.org
> Subject: Re: how to make libtool link with static system libraries
> instead of dynamic
>
> On 0
On 2015-03-06 16:35 +, Andy Falanga (afalanga) wrote:
> From: Peter Johansson [mailto:troj...@gmail.com]
> Sent: Thursday, March 05, 2015 6:46 PM
[...]
> > On 03/06/2015 09:24 AM, Andy Falanga (afalanga) wrote:
> > > I am wondering how I would make libtool link wi
On 03/06/2015 09:24 AM, Andy Falanga (afalanga) wrote:
I am wondering how I would make libtool link with static versions of already
installed libraries instead of the dynamic ones. I have something like this in
Makefile.am
pyexec_LTLIBRARIES = mylib.la
mylib_la_LDFLAGS = -Wl,-Bstatic
I am wondering how I would make libtool link with static versions of already
installed libraries instead of the dynamic ones. I have something like this in
Makefile.am
pyexec_LTLIBRARIES = mylib.la
mylib_la_LDFLAGS = -Wl,-Bstatic
mylib_la_LIBADD = -lz -lrt -lboost_python
The problem is
le. However, when
make is run, it seems that libtool yanks the libraries between --whole-archive
and --no-whole-archive and places them elsewhere. That is, I always ended with
"-Wl,--whole-archive -Wl,--no-whole-archive" with my *.a file unceremoniously
moved to a different place in
On 16 February 2015 at 14:38, Mike Frysinger wrote:
> On 26 Nov 2014 11:20, Venkatesh Vivekanandan wrote:
> > Problem is, platform linker command doesn't have
> > --whole-archive/--no-whole-archive around the lib. Instead it comes later
> > in the command line.
>
ary V. Vaughan (gary AT gnu DOT org)
> On Feb 16, 2015, at 6:26 AM, Václav Zeman wrote:
>
> On 15 February 2015 at 22:39, Gary V. Vaughan wrote:
>>
>> Libtoolers!
>>
>> The Libtool Team is pleased to announce the release of libtool 2.4.6.
>>
>> GN
On 26 Nov 2014 11:20, Venkatesh Vivekanandan wrote:
> Problem is, platform linker command doesn't have
> --whole-archive/--no-whole-archive around the lib. Instead it comes later
> in the command line.
iirc, libtool likes to sort things for you
> How to propogate the --whole-a
On 15 February 2015 at 22:39, Gary V. Vaughan wrote:
>
> Libtoolers!
>
> The Libtool Team is pleased to announce the release of libtool 2.4.6.
>
> GNU Libtool hides the complexity of using shared libraries behind a
> consistent, portable interface. GNU Libtool ships wi
Libtoolers!
The Libtool Team is pleased to announce the release of libtool 2.4.6.
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules
Great, I verified that we nearly get the speed back:
When build xz:
libtool-2.4.5 libtool-2.4.2
bash:14s13s
dash:12s11s
// Robert
On 02/10/2015 06:35 PM, Richard Purdie wrote:
On Mon, 2015-02-09 at 23:36 +, Richard Purdie wrote:
On Mon
nfo/libtool
et to the bottom of this I made a git bisection, timing
> >>> the performance of building xz with make -j1 using each different
> >>> libtool.
> >>>
> >>> The issues come down to this commit:
> >>>
> >>> http://git.savannah.gnu
performance of building xz with make -j1 using each different
>>> libtool.
>>>
>>> The issues come down to this commit:
>>>
>>> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=0a42997c6032b9550a009a271552e811bfbcc430
>>>
>>>
Hi Richard,
> On Feb 9, 2015, at 11:36 PM, Richard Purdie
> wrote:
>
> On Mon, 2015-02-09 at 13:05 +, Richard Purdie wrote:
>> In an effort to get to the bottom of this I made a git bisection, timing
>> the performance of building xz with make -j1 using e
On Mon, 2015-02-09 at 23:36 +, Richard Purdie wrote:
> On Mon, 2015-02-09 at 13:05 +, Richard Purdie wrote:
> > In an effort to get to the bottom of this I made a git bisection, timing
> > the performance of building xz with make -j1 using each different
> > libtool
On Mon, 2015-02-09 at 13:05 +, Richard Purdie wrote:
> In an effort to get to the bottom of this I made a git bisection, timing
> the performance of building xz with make -j1 using each different
> libtool.
>
> The issues come down to this commit:
>
> http://git.
2:12 PM, Bob Friesenhahn wrote:
>>>>> I am not seeing quite the difference between libtool releases that you are
>>>>> although I see a big slowdown starting with 2.4.3. These timings are for
>>>>> optimized builds of GraphicsMagick on a 12-core GNU/Linux system
On Mon, 2015-02-09 at 10:45 +0800, Robert Yang wrote:
> On 02/06/2015 10:46 PM, Bob Friesenhahn wrote:
> > On Fri, 6 Feb 2015, Robert Yang wrote:
> >
> >>
> >>
> >> On 02/06/2015 12:12 PM, Bob Friesenhahn wrote:
> >>> I am not seeing quit
On 02/06/2015 10:46 PM, Bob Friesenhahn wrote:
On Fri, 6 Feb 2015, Robert Yang wrote:
On 02/06/2015 12:12 PM, Bob Friesenhahn wrote:
I am not seeing quite the difference between libtool releases that you are
although I see a big slowdown starting with 2.4.3. These timings are for
On Fri, 6 Feb 2015, Robert Yang wrote:
On 02/06/2015 12:12 PM, Bob Friesenhahn wrote:
I am not seeing quite the difference between libtool releases that you are
although I see a big slowdown starting with 2.4.3. These timings are for
optimized builds of GraphicsMagick on a 12-core GNU/Linux
;>>> shell: $SHELL
> >>>> compiler: $LTCC
> >>>> compiler flags: $LTCFLAGS
> >>>> linker: $LD (gnu? $with_gnu_ld)
> >>>> version: $progname (GNU libtool) 2.4.5
> >>&g
LL
>>>>> compiler: $LTCC
>>>>> compiler flags: $LTCFLAGS
>>>>> linker: $LD (gnu? $with_gnu_ld)
>>>>> version: $progname (GNU libtool) 2.4.5
>>>>> automake: `($AUTOMAKE --version) 2&
301 - 400 of 4376 matches
Mail list logo
