https://sourceware.org/bugzilla/show_bug.cgi?id=33246
--- Comment #29 from Toolybird ---
Latest patch still looking good here. Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=33246
--- Comment #13 from Toolybird ---
Yes, the updated patch appears to work fine. Thanks again.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=33246
--- Comment #11 from Toolybird ---
Thanks for the patch! It certainly fixes the initial problem we were seeing.
I'll take it for a more thorough spin a bit later on...
--
You are receiving this mail because:
You are on the CC list for the bu
https://sourceware.org/bugzilla/show_bug.cgi?id=33246
--- Comment #7 from Toolybird ---
Sam, H.J., thank you very much for taking a look! And I'm sorry about the
initial report.. it was misleading to say the least!
Here's a small testcase:
=== with 2.44 ===
[root@244 ~]# cat x.c
void
foo (void)
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: toolybird at tuta dot io
Target Milestone: ---
Hey, over at Arch Linux (x86_64) we have noticed a possible regression in 2.45
when stripping static archives. For example, our `libelf` pkg increased
https://sourceware.org/bugzilla/show_bug.cgi?id=32745
Toolybird changed:
What|Removed |Added
CC||toolybird at tuta dot io
--- Comment #4
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: toolybird at tuta dot io
Target Milestone: ---
** Please reassign this to gprofng if you believe the problem lies there **
I'm building binutils trunk on x86_64 and seeing testsuite failures in gas, but
https://sourceware.org/bugzilla/show_bug.cgi?id=29065
--- Comment #7 from Toolybird ---
Created attachment 14087
--> https://sourceware.org/bugzilla/attachment.cgi?id=14087&action=edit
gprofng test suite log
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29065
--- Comment #6 from Toolybird ---
> The problem is fixed.
Yes, thanks, the libraries are now found.
The test suite gets further but still fails for reasons I don't understand. I
don't have any JDK installed but I'm not sure that's relevant f
https://sourceware.org/bugzilla/show_bug.cgi?id=29065
--- Comment #2 from Toolybird ---
> Is it Intel or Arm ?
x86_64
> How did you run make:
> cd YOUR_BUILD_DIR/gprofng && make check
> or in another way?
Just in the usual way i.e. `make check' from the top level. I tried your way
but the re
https://sourceware.org/bugzilla/show_bug.cgi?id=29042
--- Comment #4 from Toolybird ---
This bug is a little more serious than I first thought.
Even when /usr/lib/libiberty.a does not exist, the following combination of
switches results in the wrong libiberty.a getting linked in:
--prefix=/usr
Assignee: vladimir.mezentsev at oracle dot com
Reporter: toolybird at tuta dot io
Target Milestone: ---
Building latest binutils trunk I'm getting:
Running
/build/binutils/src/binutils-gdb/gprofng/testsuite/gprofng.display/display.exp
...
ERROR: compilation of test progr
https://sourceware.org/bugzilla/show_bug.cgi?id=28968
Toolybird changed:
What|Removed |Added
CC||toolybird at tuta dot io
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=29042
--- Comment #3 from Toolybird ---
Created attachment 14063
--> https://sourceware.org/bugzilla/attachment.cgi?id=14063&action=edit
log with --verbose
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29042
--- Comment #2 from Toolybird ---
Created attachment 14062
--> https://sourceware.org/bugzilla/attachment.cgi?id=14062&action=edit
log of failing libtool/linker command invocation
--
You are receiving this mail because:
You are on the CC l
https://sourceware.org/bugzilla/show_bug.cgi?id=29042
--- Comment #1 from Toolybird ---
After studying this for a bit, I'm fairly certain it can be fixed in the same
way that libctf was fixed. i.e.
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7d53105d
For now, I'm just going to run
: binutils
Assignee: unassigned at sourceware dot org
Reporter: toolybird at tuta dot io
Target Milestone: ---
2.38 release tarball
x86_64 Arch Linux
I'm seeing a regression upon `make install' in the opcodes dir. Essentially,
the build fails because the wrong libiberty.a (i
https://sourceware.org/bugzilla/show_bug.cgi?id=28029
--- Comment #3 from Toolybird ---
Thanks Nick.
I ran another bisection (taking your latest fix into account) which arrived at
this:
ca0e11aa4ba877e180f7d40dcc5a89540740c501 is the first bad commit
commit ca0e11aa4ba877e180f7d40dcc5a89540740c
: binutils
Assignee: unassigned at sourceware dot org
Reporter: toolybird at tuta dot io
Target Milestone: ---
I noticed this while test building latest git. Probably nothing to worry about
but I'll mention it anyway.
2 tests in debuginfod.exp are showing as UNTESTED. These w
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
--- 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 #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
Toolybird changed:
What|Removed |Added
CC||toolybird at tuta dot io
--- Comment #10
https://sourceware.org/bugzilla/show_bug.cgi?id=22755
Toolybird changed:
What|Removed |Added
CC||toolybird at tuta dot io
--- Comment #5
26 matches
Mail list logo
