https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Sam James changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Sam James changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Alan Modra changed:
What|Removed |Added
Version|2.36.1 |2.36
--
You are receiving this mail bec
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #25 from Nick Alcock ---
Thanks for the heads-up!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
John changed:
What|Removed |Added
CC||bugs.sourceware@johnthomson
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #23 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Nick Alcock :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7d53105d6ed984aec255fa0eacd0405f3c1bb874
commit 7d53105d6ed984aec255fa0eacd
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #22 from Toolybird ---
> try the users/nalcock/libctf-install-relink branch now
This solves the problem I was seeing. Thanks for your efforts!
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
pat at burned dot com changed:
What|Removed |Added
CC||pat at burned dot com
--
You
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #19 from Nick Alcock ---
After a lot of struggling, I can now trigger an install-time relink and see it
triggering searches of very much the wrong place for libiberty.a (the install
tree, even if --enable-install-libiberty was not
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #21 from Nick Alcock ---
OK, try the users/nalcock/libctf-install-relink branch now. Still testing here,
but things are looking better (make check passing and install-time relinking
always linking against the libiberty in the build
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #20 from Nick Alcock ---
... never mind, doing that regresses elsewhere. Still looking at it, I'm sure
this is soluble )
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #18 from Nick Alcock ---
Yeah, that's only true if the distributor chooses to install the iibiberty.a
from GCC in /usr/lib (or, I suppose, the one from a sufficiently recnet
binutils).
I do still want to figure out how to fix this
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #17 from Toolybird ---
Just wanted to mention that while this libctf bug is still present, gcc-11 has
been released which now ships a libiberty that includes bsearch_r()
This means that building binutils with:
1. --enable-shared
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #16 from Toolybird ---
$ grep "/usr/lib " libctf/config.status
sys_lib_search_path_spec='/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0 /usr/lib /lib
'
sys_lib_dlsearch_path_spec='/lib /usr/lib /usr/lib/libfakeroot '
That looks fairly n
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #15 from Nick Alcock ---
The real question is where the -L/usr/lib is coming from. If you dig into
config.status it should become clear. I bet this is derived from some .la file
somewhere, so that libtool thinks it needs -L/usr/lib
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #14 from Toolybird ---
Figured it out! (i.e. You were right)
The relink happens to link against a system installed copy of libiberty.a
residing in /usr/lib instead of the one in the build tree. If I remove
/usr/lib/libiberty.a bef
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #13 from Toolybird ---
> -rpath /usr/local/lib
Just noticed the bug only triggers when --prefix=/usr . Any other prefix seems
to work fine.
I'm starting to think your original comment in the commit about working around
a libtool
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #12 from Nick Alcock ---
In particular, the relink line I see is:
cd /home/oranix/oracle/private/binutils-gdb/foo/libctf; /bin/sh
/home/oranix/oracle/private/binutils-gdb/foo/libctf/libtool --tag CC
--mode=relink gcc -std=gnu99 -
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #11 from Nick Alcock ---
I can confirm that libctf is being relinked during install (though ld does
not). However, for me, this does not fail: we have always installed libbfd
first and the link works.
I think I need a full log of
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Toolybird changed:
What|Removed |Added
CC||toolybird at tuta dot io
--- Comment #10
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #9 from Nick Alcock ---
OK, I'm fairly sure this is fixed on master now -- could you give it a try? (It
might well be fixed on the 2.36 branch as well.)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #8 from Allan McRae ---
I'm installing it on top of 2.36.1 (built without --enable-shared).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #7 from Nick Alcock ---
This is probably related to the version of binutils installed *before* you do a
make install. What version are you installing on top of?
This may be a dup of #27482: could you see if the
users/nalcock/ld-ct
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #6 from Allan McRae ---
I can still replicate on git master (160fe1933736c123e15199080874fcab8b9ecc65).
I build with the following configuration:
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
CXXFLAGS="-march=x86-64 -m
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Nick Alcock changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |nick.alcock at oracle
dot com
-
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Nick Alcock changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Sven changed:
What|Removed |Added
CC||sven.koehler at gmail dot com
--
You are rece
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
seanga2 at gmail dot com changed:
What|Removed |Added
CC||seanga2 at gmail dot com
--
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Stephen Casner changed:
What|Removed |Added
CC||casner at acm dot org
--- Comment #4
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #3 from Allan McRae ---
Bisected to the following commit:
1038406a8f6609ad0a449746da70393b0835f699
libctf: rip out BFD_DEPENDENCIES / BFD_LIBADD
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
Steven Noonan changed:
What|Removed |Added
CC||steven at uplinklabs dot net
--
You
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #2 from Allan McRae ---
Looking at the build output, the only difference in the commands used when
linking libctf during build and install are:
build:
-Wl,-rpath -Wl,/build/binutils/src/binutils-build/bfd/.libs
../bfd/.libs/libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27360
--- Comment #1 from Andreas Schwab ---
The reference should have been resolved from libiberty.
--
You are receiving this mail because:
You are on the CC list for the bug.
34 matches
Mail list logo
