Hi,
I've spoken about this in the past but it looks like I should mention it
again. I do extensive cross compiling of the entire Linux software stack
using OpenEmbedded and Poky (I maintain the latter). We have cross
compiling working with libtool with a variety of workarounds. This
mainly consist
Hi,
I work on OpenEmbedded/Poky and we're been experimenting with the recent
libtool sysroot support. To say I'm pleased to have this is an
understatement! We're having a few problems around incorrect RPATHs
being encoded into libraries however.
Firstly, for the first time ever for us, it appears
Hi Ralf,
Thanks for the reply.
On Thu, 2011-01-13 at 08:24 +0100, Ralf Wildenhues wrote:
> * Richard Purdie wrote on Wed, Jan 12, 2011 at 12:06:13AM CET:
> > Firstly, for the first time ever for us, it appears libtool is no longer
> > relinking our libraries at install time.
>
On Fri, 2012-10-26 at 13:27 -0500, Bob Friesenhahn wrote:
> On Fri, 26 Oct 2012, Yaroslav Bulatov wrote:
>
> > Oops my badthat was a bad paste from some auto-generated code.
> >
> > This is basically a modified version of .pc file I get when building
> > zlib. Not sure how useful this is becau
On Thu, 2013-09-19 at 15:58 -0400, Michael Young wrote:
> I'm trying to do a staged build/install of libgmp(xx) release 5.1.2.
> This is
> part of an effort to develop a "general" build system (mostly bash
> scripts, make
> files, etc.) for toolchains I will be using. I intend to use these
> scri
On Thu, 2014-03-20 at 18:07 +1300, Gary V. Vaughan wrote:
> On Mar 20, 2014, at 5:37 AM, Arnout Vandecappelle
> wrote:
> > [Please keep me in CC, I'm not on the list]
> > Dear libtool maintainers,
>>
> > Is there a possibility for a new libtool release in the foreseeable
> > future?
>
> Yes, absol
On Mon, 2015-02-02 at 08:19 -0600, Bob Friesenhahn wrote:
> On Mon, 2 Feb 2015, Robert Yang wrote:
> > It seems that libtool (2.4.4) has increased the packages build time, after
> > a rough investigation, it maybe because new libtoolize needs run a m4
> > command:
>
> Did you time 'libtoolize' and
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 quite the difference between libtool releases that you are
> >>>
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.
On Mon, 2015-02-09 at 23:36 +, Richard Purdie wrote:
> On Mon, 2015-02-09 at 13:05 +0000, 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 Tue, 2015-02-10 at 10:53 +, Gary V. Vaughan wrote:
> On Feb 10, 2015, at 10:35 AM, Richard Purdie
> wrote:
> > On Mon, 2015-02-09 at 23:36 +0000, Richard Purdie wrote:
> >> On Mon, 2015-02-09 at 13:05 +, Richard Purdie wrote:
> >>> In an effort to g
On Mon, 2015-03-09 at 18:28 +, Mike Gran wrote:
> I don't know if y'all saw this blogpost where a guy pushed
> the sed regular expression handling into bash-specific
> regular expressions when bash was available. He claims
> there's a significant performance improvement because of
> reduced fo
On Fri, 2016-08-12 at 22:06 +0200, Jan Engelhardt wrote:
> Given certain circumstances, libtool 2.4.2 fails to install a
> library.
> (a) The target directory spec contains a trailing slash
> (b) The library to install is linking to another just-built one in a
> different path.
FWIW we have this
On Thu, 2020-01-02 at 16:24 -0600, Bob Friesenhahn wrote:
> On Thu, 2 Jan 2020, wf...@niif.hu wrote:
> > > If Libtool were to depend on non-portable features, [...] then it
> > > could not longer be described as a portability tool.
> >
> > In my understanding, Libtool is a portability shim, provid
On Sun, 2021-11-21 at 13:14 -0600, Alex Ameen wrote:
> I just took a look at those. Good catches on the typos, I probably would
> not have noticed them just reading the script myself. Same thing with
> the M4 `[]' quoting issue ( classic pitfall ). I'll get these merged ASAP.
>
> For the non-Lin
On Sat, 2022-02-05 at 21:06 -0500, Mike Frysinger wrote:
> On 05 Feb 2022 15:15, Alex Ameen wrote:
> > This is a good question. I plan on making a new release this month.
> >
> > When I first adopted the project I ambitiously thought I'd manage to
> > create a new release after about a month; but
Hi,
It was great to see a libtool release, thanks for that!
I upgraded Yocto Project to it in time for our LTS release:
https://git.yoctoproject.org/poky/commit/?id=ff7b41573842a403c81f58bee41fc8163a9d7754
so far things seem reasonable, we've had a few minor issues but they're not
really libtoo
On Mon, 2022-04-18 at 07:39 -0400, Carlos O'Donell wrote:
> On 4/17/22 10:06, Bob Friesenhahn wrote:
> > The libtool I was using (originating from Ubuntu Linux) stripped the
> > rpath (which was provided like '-Wl,rpath=/usr/lib') so I was unable
> > to embed an rpath in the libcurl I built so that
On Fri, 2024-07-26 at 19:13 +0300, Ileana Dumitrescu wrote:
> On 26/07/2024 03:26, Bruno Haible wrote:
> > Hi Ileana,
> >
> > I tested a GNU gettext tarball, built with libtool-2.5.1, on
> > several platforms,
> > including on Solaris 11.3 (where libtool-2.4.7 had a problem). No
> > issues found;
Josh Triplett freedesktop.org> writes:
> Thus, I wrote Dolt, a drop-in replacement for libtool's compilation
> mode. Dolt runs any necessary system-specific or
> configuration-specific logic as part of configure, writes out a simple
> shell script "doltcompile"[1], and substitutes it for libtool
Hi,
On Sun, 2008-04-13 at 08:21 -0400, Gary V. Vaughan wrote:
> On 13 Apr 2008, at 07:55, Richard Purdie wrote:
> > [1] Are there any plans to support sysroots with libtool?
>
> No one is sending us bug reports or patches... so we don't even know
> there is a problem!
Ok
Hi Ralf,
On Sun, 2008-04-13 at 17:09 +0200, Ralf Wildenhues wrote:
> * Richard Purdie wrote on Sun, Apr 13, 2008 at 04:59:26PM CEST:
> >
> > * the person who integrated libtool into OE has moved onto other things
> > and the knowledge for a lot of the "magic" w
On Sun, 2008-04-13 at 22:26 +0200, Ralf Wildenhues wrote:
> * Richard Purdie wrote on Sun, Apr 13, 2008 at 08:53:10PM CEST:
> >
> > The patches we're using are publicly available as:
> > http://svn.o-hand.com/view/poky/trunk/meta/packages/libtool/libtool-1.5.10/
>
Hi,
On Wed, 2008-04-16 at 19:03 +0200, Vincent Torri wrote:
> I'm using libtool 2.2.3a (cvs, actually) and i'm trying to find out why
> some lib are not configured correctly, while other are.
>
> My problem is that ECHO and OBJDUMP are not defined when I'm configuring
> libpng 1.2.26, while it'
On Wed, 2008-04-16 at 23:56 +0200, Ralf Wildenhues wrote:
> * Richard Purdie wrote on Wed, Apr 16, 2008 at 07:10:54PM CEST:
> > To 'fix' the echo issue I added:
> >
> > http://svn.o-hand.com/view/poky/trunk/meta/packages/libpng/libpng-1.2.16/makefile
Hi,
I've had reports of Poky breaking with libtool 2.2.2 and have isolated
this to people using dash as their /bin/sh provider (Poky runs the
configure script with /bin/sh). When used in this combination, the
global_symbol_pipe expression becomes corrupted in the generated libtool
file amongst oth
Hi,
I've noticed another problem with two packages in poky, prelink and
libvorbis. Both packages have areas where LDFLAGS="-all-static" is used.
The problem comes about since Poky sets CC to "ccache gcc", then libtool
puts the -static flag between ccache and gcc.
To reproduce:
wget http://www.v
Hi Ralf,
On Tue, 2008-04-22 at 21:43 +0200, Ralf Wildenhues wrote:
> Thanks for the bug report, and especially for providing an example to
> reproduce it!
>
> > libtool: link: ccache -static gcc -O20 -ffast-math -D_REENTRANT
> > -fsigned-char -DUSE_MEMORY_H -o decoder_example decoder_example.o
Hi,
As previously mentioned, I've been stress testing libtool 2.2.2 with
Poky a bit.
I've found one issue when I tested the darwin builds, specifically that
it tried to use "otool" and "otool64" and not the versions with the host
prefix which my setup has. I fixed this with the patch below which
On Fri, 2008-05-02 at 01:03 -0500, Peter O'Gorman wrote:
> Peter O'Gorman wrote:
> > Richard Purdie wrote:
> >> Hi,
> >>
> >> As previously mentioned, I've been stress testing libtool 2.2.2 with
> >> Poky a bit.
> >>
> &g
On Thu, 2008-06-12 at 22:03 +0300, Alon Bar-Lev wrote:
> On 6/12/08, Roumen Petrov <[EMAIL PROTECTED]> wrote:
> > It look like an enhancement request. libtool to obey as example
> > FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1
> > , ... and $FAKEROOT/pathN and later in /path1,.
t*)
> for dir in /lib64 /usr/lib64; do
> test -d $dir &&
> sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec $dir"
> done
> ;;
> esac
Just as a datapoint, my standard ubuntu 64 bit desktop has /lib64 as a
symlink to /lib which h
tion...
Just for reference, pkg-config should not break cross-compilation after
the addition of sysroot support to it. I keep meaning to look into
sysroot support for libtool too, I just haven't had the time yet :(.
Cheers,
Richard
--
Richard Purdie
Intel Open Source Technology C
On Thu, 2009-02-26 at 14:16 +0100, Andreas Frisch wrote:
> the guys from gstreamer went through and moved to a newer libtool
> version in their plugin packages. since then i can't crosscompile
> anymore them with openembedded like with the previous releases. i
> described the problem here:
> http:/
ould be a much better
way to solve this?
Linux does seem to have good dynamic linker support and its a shame
libtool effectively drags it down to a lower common denominator of other
platforms with worse support.
Cheers,
Richard
--
Richard Purdie
Intel Open Source Technology Centre
___
http://lists.gnu.org/mailman/listinfo/libtool
On Fri, 2010-02-12 at 16:34 +0100, Thomas Petazzoni wrote:
> I'm a contributor to the Buildroot project (http://www.buildroot.org),
> a build system for embedded Linux systems. We integrate many packages
> in order to ease their cross-compilation.
>
> I'm facing an issue with several packages wher
On Fri, 2010-02-12 at 19:34 +0100, Thomas Petazzoni wrote:
> I suppose you apply these modifications to a libtool that you are
> compiling. However, libtool is typically already embedded in each
> upstream tarball. Do you run autoreconf on all packages, so that a
> newer libtool script gets generat
37 matches
Mail list logo
