The lack of FILECMD was causing failures for mips64 builds as -m elf was
being passed to LD which isn't supported on our targets.
Signed-off-by: Richard Purdie
---
m4/libtool.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index c5be6436..bbf2d
clang uses -rtlib and --unwindlib to select proper compiler runtime in
some cases. Therefore pass these options to linker when found in
ldflags
* build-aux/ltmain.in: Handle clang linker options
---
build-aux/ltmain.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
If lto is enabled, we need the prefix-map variables to be passed to the linker
to correctly link the objects using correctly mapped paths.
Add these to the list of options libtool passes through.
* build-aux/ltmain.in: Handle prefix-map compiler options
---
build-aux/ltmain.in | 2 ++
1 file
If $CC has --sysroot=/, it is a valid configuration however libtool will
then set lt_sysroot to "/".
This means references like $lt_sysroot$libdir become //usr/lib instead
of the more normally expected /usr/lib. This may or may not break something
but certainly is confusing to the user and gives
On Tue, 2024-01-16 at 20:47 -0500, Mike Frysinger wrote:
> On 16 Jan 2024 15:14, Richard Purdie wrote:
> > --- a/build-aux/ltmain.in
> > +++ b/build-aux/ltmain.in
> > @@ -7,7 +7,6 @@
> > # Copyright (C) 1996-2019, 2021-2024 Free Software Foundation, Inc.
> &
On Mon, 2024-01-15 at 17:00 -0500, Mike Frysinger wrote:
> On 25 Oct 2021 15:33, Richard Purdie wrote:
> > Update libtool.m4 to resolve a problem with lt_sysroot not being properly
> > updated if the option '--with[-libtool]-sysroot' is not provided when
> > running t
If $CC has --sysroot=/, it is a valid configuration however libtool will
then set lt_sysroot to "/".
This means references like $lt_sysroot$libdir become //usr/lib instead
of the more normally expected /usr/lib. This may or may not break something
but certainly is confusing to the user and gives
On Mon, 2024-01-15 at 20:10 -0500, Mike Frysinger wrote:
> On 25 Oct 2021 15:33, Richard Purdie wrote:
> > We don't want to add RPATHS which match default linker search paths, they're
> > a waste of space. This patch filters libtools list of paths to encoode and
> > removes t
If lto is enabled, we need the prefix-map variables to be passed to the linker
to correctly link the objects using correctly mapped paths.
Add these to the list of options libtool passes through.
* build-aux/ltmain.in: Handle prefix-map compiler options
---
build-aux/ltmain.in | 3 ++-
1 file
clang uses -rtlib and --unwindlib to select proper compiler runtime in
some cases. Therefore pass these options to linker when found in
ldflags
* build-aux/ltmain.in: Handle clang linker options
---
build-aux/ltmain.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
The name of the system contains the string "nios2". This string
is caught by the some of the greedy checks for OS/2 in libtool,
in particular the *os2* branches of switch statements match for
the nios2 string, which results in incorrect behavior of libtool.
Switch to use $host_os instead of $host
Somehow my original reply ended up blank, sorry. I've retyped it from
memory as best I can.
On Mon, 2024-01-15 at 20:08 -0500, Mike Frysinger wrote:
> On 25 Oct 2021 15:33, Richard Purdie wrote:
> > This patch renames the --with-sysroot option to --with-libtool-sysroot
> > to
gt; the bits which received comments (unclear to me what we need
> to do for those)?
I'd second that, I'd love to get the easy ones sorted and am happy to
try and help with the others, just not quite sure where we stand at the
moment.
Cheers,
Richard
nity
> > check that they fail on the mainline branch I can move forward. I'm ~99%
> > sure this patch will have no effect on those results.
> >
> >
>
> FWIW, given the comments on the main libtool ML, I at least am happy to drop
> this one for now, and revisit later.
as linking with "-z
nodeflib" or some fairly convoluted setups but I suspect those would have other
issues too.
Cheers,
Richard
y identify regressions from our perpective
quickly.
Thanks,
Richard
there.
I know there are some Yocto Project patches for issues we've collected from
across the embedded ecosystem over the last few years that I rebased and posted
in the hope they could be merged. I'd rather we got to those in due course and
had a release though! :)
Cheers,
Richard
r use in OE/YP which is widely used for
cross compiling for Linux/mingw and others. We tend to find sysroot and cross
compile issues in particular and we also find reproducibility and parallel make
race issues.
If you have any questions or concerns on any of those I'm happy to try and help.
Cheers,
Richard
the paths as equal. Strip both paths to ensure this works
reliably.
Signed-off-by: Richard Purdie
---
build-aux/ltmain.in | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96b37003..3d5dcd0a 100644
--- a/build-aux/ltmain.in
There is a bug where RPATHs could end up containing sysroot values when
cross compiling which is obviously incorrect. Strip out sysroot components
from libdir when building RPATH values to avoid this.
Signed-off-by: Richard Purdie
---
build-aux/ltmain.in | 14 --
1 file changed, 12
autoconf to avoid this race.
Signed-off-by: Mingli Yu
Signed-off-by: Richard Purdie
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index 6b546092..84795d87 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -370,7 +370,7 @@ lt_configure_deps
Update libtool.m4 to resolve a problem with lt_sysroot not being properly
updated if the option '--with[-libtool]-sysroot' is not provided when
running the 'configure' script for a package so that "/" as a sysroot
is handled correctly by libtool.
Signed-off-by: Richard Purdie
---
m4/
n.
Signed-off-by: Richard Purdie
---
build-aux/ltmain.in | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 96238350..6fb58ed2 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -7672,
From: Khem Raj
When using a sysroot we should append it to libdir, which is helpful in
cross builds as the system is staged in the sysroot. For normal builds,
i.e. when lt_sysroot is not set, it will still behave the same and add
-L/usr/lib to the relink command.
Signed-off-by: Richard Purdie
race.
Signed-off-by: Mingli Yu
Signed-off-by: Richard Purdie
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index 84795d87..8c9949ed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -333,7 +333,7 @@ EXTRA_DIST += $(lt_aclocal_m4
If lto is enabled, we need the prefix-map variables to be passed to the linker.
Add these to the list of options libtool passes through.
Signed-off-by: Richard Purdie
---
build-aux/ltmain.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/build-aux/ltmain.in b/build-aux
patch adds an explicit check for *nios2* before the *os2*
checks to prevent the OS/2 check incorrectly trapping the nios2
as well.
Signed-off-by: Marek Vasut
Signed-off-by: Richard Purdie
---
build-aux/ltmain.in | 20
1 file changed, 20 insertions(+)
diff --git a/build-aux/l
.
Signed-off-by: Khem Raj
Signed-off-by: Richard Purdie
---
m4/libtool.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 180dd9d1..022c1292 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7560,7 +7560,7 @@ if AC_TRY_EVAL(ac_compile
For reproducibilty, stop encoding the hostname into the libtool script, this
isn't
really adding much to debugging and most distros are carrying such a patch now
as
reproducibility is important.
Signed-off-by: Richard Purdie
---
m4/libtool.m4 | 1 -
1 file changed, 1 deletion(-)
diff --git
-by: Richard Purdie
---
m4/libtool.m4| 12 ++--
tests/sysroot.at | 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f2d1f398..de2f1ebf 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1246,28 +1246,28 @@ _LT_DECL([], [ECHO], [1
it
simpler to send the set out for review together as a set.
Cheers,
Richard
Khem Raj (3):
libtool.m4: Rename the --with-sysroot option to avoid conflict with
gcc/binutils
ltmain.in: Add missing sysroot to library path
libtool: Check for static libs for internal compiler libraries
Marek
h the amount of knowledge of weird older
systems needed is going to be a struggle which only gets worse over
time :(
I do worry about the future here as libtool is a key part of the
autotools fabric but its most likely to be wholesale replaced given how
things are trending.
Cheers,
Richard
.
FWIW we have this patch:
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-devtools/libtool/libtool/trailingslash.patch
which seems to help. We've never been able to clean it up enough to
submit upstream or have a reliable test case for it though :(
Cheers,
Richard
[patch follows be
e should check and maintain the whole libtool.m4
> file?!
>
> kind regards
> christian
I filed https://savannah.gnu.org/support/index.php?108987 a few months ago,
are you saying the proposed patches don't fix this?
--
Richard PALO
use as documented, that is to respect the environment
if these variables
are set, but naturally -- if set -- they will be just the path to the tool and
as such can in no
way expect that '-f' is specified (which is '--force' under the Gnu flavours of
these tools).
--
Richard
Additional Item Attachment, sr #108987 (project libtool):
File name: 0001-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch
Size:1 KB
File name: 0002-avoid-issues-if-CP-MV-or-RM-are-predefined-in-the-ex.patch
Size:0 KB
___
Reply
use as documented, that is to respect the environment
if these variables
are set, but naturally -- if set -- they will be just the path to the tool and
as such can in no
way expect that '-f' is specified (which is '--force' under the Gnu flavours of
these tools).
--
Richard PALO
Follow-up Comment #3, sr #108987 (project libtool):
The attached patchsets seem to get over the issue for RM, as well as for
eventual problems for CP or MV.
the first patchset (0001-*) is for the master libtool repo,
and the second (0002-*) is for gl-mod/bootstrap in order to
generate the new
Follow-up Comment #2, sr #108987 (project libtool):
It appears that the shell assignment expectation may be erroneous,
in that ": ${RM="rm -f"}" will only replace RM if RM is not defined.
perhaps what is intended is more along the lines of:
RM="${RM:=rm} -f"
(NB it would probably be easier to
Follow-up Comment #1, sr #108987 (project libtool):
another simple, but enlightening way to see this is
$ env RM=/usr/bin/rm gmake
or
$ env RM=/usr/bin/rm gmake check
it appears to be more involved than simply updating '${RM}r' to '${RM} -r' in
ltmain.in
works (this is after a --mode=compile stage):
richard@omnis:/home/richard/src/tlibtool$ ../libtool/libtool -v --tag=CXX
--mode=link g++ -shared -o libfoo.la -Wl,-h libfoo.so foo.lo
libtool: link: rm -fr .libs/libfoo.a .libs/libfoo.la
libtool: link: ar cr .libs/libfoo.a .libs/foo.o
libtool: link:
Le 02/11/13 23:45, Richard PALO a écrit :
> Le 02/06/10 05:24, Yaakov (Cygwin/X) a écrit :
>> On Sat, 15 May 2010 09:07:49 +0200
>> Bart Van Assche <bvanass...@acm.org> wrote:
>>> This behavior has been observed with libtool version 2.2.6.
>>
>> Bug conf
form, it can't really be merged and my
shell knowledge and lack of contribution agreement to GNU are likely
blocking issues along with a lack of time :(
Cheers,
Richard
___
https://lists.gnu.org/mailman/listinfo/libtool
On Tue, 2015-02-10 at 10:53 +, Gary V. Vaughan wrote:
On Feb 10, 2015, at 10:35 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
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
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.
The issues come down
somewhere else. Any ideas what else in
that rather large change may be causing this?
Cheers,
Richard
___
https://lists.gnu.org/mailman/listinfo/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.savannah.gnu.org/cgit/libtool.git
Le 09/11/13 07:44, Richard PALO a écrit :
I believe Chuck is oriented in the right direction.
A good example is with -fstack-protector.
gcc/g++ knows how to link depending upon whether the platforms libc has
SSP support or not.
I doubt very much that libtool wants to figure out whether to add
Le 09/11/13 07:44, Richard PALO a écrit :
I believe Chuck is oriented in the right direction.
A good example is with -fstack-protector.
gcc/g++ knows how to link depending upon whether the platforms libc has
SSP support or not.
I doubt very much that libtool wants to figure out whether to add
could get some into a form that they'd be accepted
upstream.
Cheers,
Richard
___
https://lists.gnu.org/mailman/listinfo/libtool
Le 22/01/14 17:54, Richard PALO a écrit :
I already have a question to see this through:
Does it sound reasonable to add support to inherit_linker_flags
'-fstack-protector|-fstack-protector-all'
in a similar manner to '-pthreads' given the compiler needs to have this
option in order to include
Le 06/12/13 09:51, Peter Rosin a écrit :
[dropping libtool-patches@]
On 2013-11-12 12:24, Peter Rosin wrote:
[re-adding libtool@]
On 2013-11-11 16:10, Bob Friesenhahn wrote:
On Mon, 11 Nov 2013, Peter Rosin wrote:
Quite a lot of effort went into making this work the way it currently does.
I already have a question to see this through:
Does it sound reasonable to add support to inherit_linker_flags
'-fstack-protector|-fstack-protector-all'
in a similar manner to '-pthreads' given the compiler needs to have this
option in order to include the correct libraries...
Le 17/01/14 15:02, Rainer Orth a écrit :
As reported in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452
the default for opt_duplicate_compiler_generated_deps can cause
exception handling/unwinding failures on 64-bit Solaris 10+/x86 when the
underlying gcc bug
Le 08/11/13 20:07, Charles Wilson a écrit :
On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:
Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times? It wants to assure that static
Le 02/06/10 05:24, Yaakov (Cygwin/X) a écrit :
On Sat, 15 May 2010 09:07:49 +0200
Bart Van Assche bvanass...@acm.org wrote:
This behavior has been observed with libtool version 2.2.6.
Bug confirmed. When code is compiled with -fstack-protector{,-all},
GCC emits extra code to check for buffer
can run on linux, windows
and osx.
Cheers,
Richard
___
https://lists.gnu.org/mailman/listinfo/libtool
Follow-up Comment #31, sr #108201 (project libtool):
apparently Joyent believe that this isn't closed, if there is somebody that
has tested this too could determine whether or not to close the issue as
fixed, thanks in advance.
___
Reply
Thank you for the thoughtful response.
On Sun, 2013-02-24 at 10:50 -0600, Bob Friesenhahn wrote:
On Wed, 20 Feb 2013, Richard Shann wrote:
In the GNU/Denemo project we are trying to cross-build a for windows on
Debian stable using static libraries. The libtool step is re-ordering
, but is moved later when libtool executes the
linker. (Or so at least is my reading of this log).
Richard Shann
888
[...]
/bin/bash ../libtool --tag=CXX --mode=link i686-pc-mingw32-g++ -g -O2
-o denemo.exe denemo_types.o commands.o calculatepositions.o
changenotehead.o chordops.o
Follow-up Comment #30, sr #108201 (project libtool):
The following patch to export.at seems to work on solaris
now testing for ELF in the shared object and using shrext_cmds to generate the
.so extension.
(file #27141)
___
Additional
Follow-up Comment #27, sr #108201 (project libtool):
This is fine with me.
When *is* the next release planned then?
In the meanwhile I will try to finish a pkgsrc patch to the already released
bits (which seems to complain with auto* tools)...
cheers
Follow-up Comment #25, sr #108201 (project libtool):
These are good arguments, I offer as well some observations and/or arguments
before I sign off...
1. I thought about that last night, that *was* the advantage of elfdump, but
not all ELF systems have elfdump and objdump is used instead!
Follow-up Comment #21, sr #108201 (project libtool):
Here is the git diff for master (apparently the same except for the file
path).
(file #27107)
___
Additional Item Attachment:
File name: libtool.m4.git-diff-master Size:1 KB
TESTSUITEFLAGS=45 -d
The test fails with the following extract from
tests/testsuite.dir/045/testsuite.log :
==
eval '/home/richard/src/libtool/libtool --mode=link g++ -g -O2 -no-undefined
-o liba.la a.lo
-rpath
/home/richard/src/libtool/tests/testsuite.dir/045/inst/lib
Follow-up Comment #17, sr #108201 (project libtool):
I gather that your gcc is rather ancient (4.5.3 from april 2011) but I cannot
determine which version of libtool you are using.
Would it be possible to upgrade gcc to the latest 4.7.2 and
git checkout v2.4.2
in order to update your
Follow-up Comment #12, sr #108201 (project libtool):
perhaps to refine the test a bit more, would it be possible to check that the
value of SONAME is the value expected.
With elfdump, the SONAME could be extracted for example by:
elfdump -d $soname | grep SONAME | awk '{printf $4}'
Apparently
Follow-up Comment #13, sr #108201 (project libtool):
if the solaris developer/gnu-binutils or pkgsrc/devel/binutils is installed,
then objdump is on the system.
Just noticed that libtool's configure found objdump:
richard@devzone:~/src/libtool$ grep objdump config*
config.log:configure:5686
Follow-up Comment #5, sr #108201 (project libtool):
Here is my feable and first attempt to detect the problem using the
testsuite.
First, the test export.at seems to work by default, but it is only a gcc
(simple 'C') test:
richard@devzone:~/src/libtool$ gmake check-local TESTSUITEFLAGS=45 -d
cd
Follow-up Comment #6, sr #108201 (project libtool):
And here is the diff for the proposed patch.
After cleanup and rebuilding (seemed like a zillion autoreconfs)
running the export tests as indicated (both for standard and CC=g++) are
successful.
richard@devzone:~/src/libtool$ git diff --staged
Follow-up Comment #8, sr #108201 (project libtool):
Bob, please see comment #5
As I indicated, local test n° 45 export.at is the existing test.
I added the following line :
AT_CHECK([elfdump -d .libs/liba.so | grep SONAME],[], [ignore], [ignore])
to ensure that the SONAME was being added,
Follow-up Comment #9, sr #108201 (project libtool):
BTW Bob, perhaps you didn't catch that I did a
$git checkout v2.4.2
since it appears much has changed since the last stable.
This is why, I believe, the tests indicate
## GNU Libtool 2.4.2 test suite. ##
Follow-up Comment #11, sr #108201 (project libtool):
I guess I can add the following:
1. regarding -no-undefined, when I changed this to avoid the syntax error on
solaris (which should be, for example, -Wl,--no-undefined), the linker
complained that it was a duplicate option implying, I believe,
. ##
## - ##
151 tests behaved as expected.
17 tests were skipped.
gmake[3]: Leaving directory `/home/richard/src/libtool'
gmake[2]: Leaving directory `/home/richard/src/libtool'
gmake[1]: Leaving directory `/home/richard/src/libtool'
GFDL_version
0.12 GFDL_version
...
libtool_m4_cc_basename
sed: -e
Follow-up Comment #3, sr #108201 (project libtool):
Hello Bob,
I wonder too, which is why I indicated at the end of my last comment:
does libtool not like pkgsrc version of sed?
richard@devzone:~/src/libtool$ which sed
/opt/pkg/gnu/bin/sed
richard@devzone:~/src/libtool$ grep 'SED
Follow-up Comment #4, sr #108201 (project libtool):
I was working off of master. With git blame I noticed that the strcmp problem
was introduced recently, so I'm trying over after git checkout v2.4.2, which
is the latest tarball version I've tested with pkgsrc.
HEAD is now at fdb4c54... Release
URL:
http://savannah.gnu.org/support/?108201
Summary: libtool problems with -export-symbols-regex on
solaris with gcc-4.7.x
Project: GNU Libtool
Submitted by: risto3
Submitted on: lun. 10 déc. 2012 13:58:02 GMT
Category:
get any
response to the libtool sysroot problems I reported a while back.
Cheers,
Richard
___
https://lists.gnu.org/mailman/listinfo/libtool
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.
That's weird, I don't
explain the correct behaviour I might be able to come
up with some patches to help fix things! :)
Cheers,
Richard
http://git.savannah.gnu.org/cgit/libtool.git/tree/libltdl/config/ltmain.m4sh?id=9167aecabd12c5afe7a65d45dc73f8c92ab42f05
line 7240:
# Test again, we may have decided not to build
rolling on patches eventually
but I'm not going to get to that soon, much as I wish it were otherwise.
Cheers,
Richard
___
http://lists.gnu.org/mailman/listinfo/libtool
On Wed, Mar 31, 2010 at 8:33 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
* Richard Guenther wrote on Wed, Mar 31, 2010 at 11:02:39AM CEST:
On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues wrote:
1) Autoconf-generated configure tests often fake the prototype of some
function; e.g
be optional, only things that LTO does not get
correct are currently diagnosed IIRC.
Thanks,
Richard.
Thanks for reading this far.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
installing packages,
particularly modifying the .la files to be uninstalled to get the
sysroot to work properly. I'd love to teach libtool about sysroots and
make it work properly but as yet have never had the time to look into
it.
Cheers,
Richard
for example...
Cheers,
Richard
___
http://lists.gnu.org/mailman/listinfo/libtool
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
for all your help. And sorry for the long time in
replying, have been away for the last 2 weeks.
Richard
or anonymized would be ok), then be my guest.
Great, thanks. In that case, sorry for the ping: I hadn't realised you
had access to these.
Richard
on that myself.
Richard
Richard Sandiford richa...@transitive.com writes:
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Richard Sandiford wrote on Fri, Apr 24, 2009 at 06:35:20PM CEST:
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:53:23AM CET
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Richard Sandiford wrote on Fri, Apr 24, 2009 at 06:35:20PM CEST:
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:53:23AM CET:
AIX nm lists weak defined symbols like any other global symbol
Hi Ralf,
Thanks for the review, and sorry for the long time it's taken to reply.
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:49:17AM CET:
If you try to configure libtool to build shared libraries on AIX,
it prints the following message
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Richard Sandiford wrote on Mon, Mar 16, 2009 at 10:53:23AM CET:
AIX nm lists weak defined symbols like any other global symbol,
whereas GNU nm lists them as W. The export_symbols_cmds for
GNU nm on AIX should therefore look for W in addition
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 Centre
___
http://lists.gnu.org/mailman
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 has 64 bit libraries in it.
Cheers,
Richard
--
Richard Purdie
Intel Open Source Technology Centre
but this means you can't use staging as a
chroot. I've not had time to look into doing anything about this feature
but I would love to see it!
Cheers,
Richard
___
http://lists.gnu.org/mailman/listinfo/libtool
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.
I've found one issue when I tested the darwin builds, specifically that
it tried to use otool
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.
I've found one issue when I tested the darwin builds, specifically that
it tried to use otool
is
fine for Poky since its always cross compiling but its a sign a better
fix is probably needed in general.
Regards,
Richard
Index: libtool-2.2.2/libltdl/config/ltmain.m4sh
===
--- libtool-2.2.2.orig/libltdl/config/ltmain.m4sh
../lib/.libs/libvorbis.a -lm /usr/lib/libogg.a
Confirmed. Fixed as below, committed, put you in THANKS.
I've confirmed the fix, added it to Poky and dropped the hacks I had,
thanks!
Cheers,
Richard
1 - 100 of 135 matches
Mail list logo
