[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 --- Comment #2 from Peter Damianov --- I see. Ideally, ld wouldn't be doing that. One option could be outputting to a temp file, and then renaming it after linking finishes successfully. I'll try taking a look at what mold does for this case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27566] [RISC-V] relocation truncated to fit: R_RISCV_GPREL_I against aymbol
https://sourceware.org/bugzilla/show_bug.cgi?id=27566 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115166 CC||pinskia at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31704] [avr] Support avr-objdump -P avr-deviceinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=31704 Georg-Johann Lay changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |2.43 --- Comment #3 from Georg-Johann Lay --- Added in v2.43 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31687] [avr] Output of avr-objdump -P mem-usage missing .rodata
https://sourceware.org/bugzilla/show_bug.cgi?id=31687 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |2.43 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Georg-Johann Lay --- Fixed in v2.43 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 --- Comment #1 from Andreas Schwab --- See ld/ldlang.c:lang_process, ld opens the output before processing the input files. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31726] et/config.ac etc/Makefile.am release
https://sourceware.org/bugzilla/show_bug.cgi?id=31726 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Nicolas, Oops - thanks for pointing this. I have checked in a small patch to the src-release.sh script - the one that is responsible for creating the release tarballs. It turns out that there are some other files in the etc/ directory which were also being (accidentally) omitted, so I have added those as well. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31726] et/config.ac etc/Makefile.am release
https://sourceware.org/bugzilla/show_bug.cgi?id=31726 --- Comment #1 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4af0542142732be2522cbbcc7ad318ab57933d28 commit 4af0542142732be2522cbbcc7ad318ab57933d28 Author: Nick Clifton Date: Mon May 20 16:12:53 2024 +0100 Add extra files found in etc/ sub-directory to ETC_SUPPORT in src-release.sh PR 31726 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 Peter Damianov changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80182 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31761] New: Linker deletes output file even if linking fails
https://sourceware.org/bugzilla/show_bug.cgi?id=31761 Bug ID: 31761 Summary: Linker deletes output file even if linking fails Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: peter0x44 at disroot dot org Target Milestone: --- For cases of compiler commands like: gcc -o file.c -lm file.c gets deleted, despite that the linking fails (undefined reference to main) gcc -fuse-ld=lld and -fuse-ld=mold don't have this problem, and the "output" remains intact regardless of the mistake in the command. Both BFD and gold will delete file.c in this case. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31395] Wrong search path for DT_NEEDED libs on FreeBSD under gcc -m32
https://sourceware.org/bugzilla/show_bug.cgi?id=31395
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1 from Nick Clifton ---
(In reply to Brooks Davis from comment #0)
Hi Brooks,
> When invoked via gcc -m32 on a FreeBSD amd64 system, ld searches for
> DT_NEEDED libraries as though it were on an i386 system and thus fails
> to find them.
Err, maybe I am misunderstanding this, but doesn't using -m32 imply that the
linker should act as if it is building for an i386 system ?
> Confusingly that is true even though
> gcc passes -L/usr/lib/../lib32 to ld. I belive this is due to this
> logic:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldelf.c;
> h=04045acbf3dc56947edb15e5818dd5b69fd9;hb=HEAD#l1091
Which makes sense. That logic is duplicating how the system loader works, and
since the system loader does not have access to the -L options generated by
gcc, that code also ignores them.
> Further tracing shows that gcc attempts to communicate the correct paths
> via a LIBRARY_PATH variable, but I don't think binutils looks for that
> at all:
It doesn't - and nor does the system loader. But if gcc used LD_LIBRARY_PATH,
that might work.
Does FreeBSD support cross linking ? If not, then would a patch like this
solve your problem:
diff --git a/ld/configure.tgt b/ld/configure.tgt
index f937f78b876..a68f2313850 100644
--- a/ld/configure.tgt
+++ b/ld/configure.tgt
@@ -1113,7 +1113,7 @@ case "${target}" in
;;
*-*-freebsd*)
- NATIVE_LIB_DIRS='/lib /usr/lib /usr/local/lib'
+ NATIVE_LIB_DIRS='/lib /usr/lib /usr/local/lib /lib/lib32'
;;
hppa*64*-*-hpux11*)
How is the linker configured ?
In particular does it support the elf_i386_fsbd emulation ?
If it does, what shows up the SEARCH_DIR entries for that emulation's built in
script ? ie:
ld -m elf_i386_bfd --verbose | grep SEARCH_DIR
On my (cross-hosted) build I get:
SEARCH_DIR("/usr/local/i386-pc-freebsd/lib32");
SEARCH_DIR("/usr/local/i386-pc-freebsd/lib");
Which implies to me that the linker already knows about the /lib32 directory,
but since I am running a cross-hosted linker, it prepends
/usr/local/i386-pc-freebsd/ to the path.
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31687] [avr] Output of avr-objdump -P mem-usage missing .rodata
https://sourceware.org/bugzilla/show_bug.cgi?id=31687 --- Comment #4 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e8c83191cc6fee517d2029109c61981b4092439d commit e8c83191cc6fee517d2029109c61981b4092439d Author: Georg-Johann Lay Date: Mon May 20 13:33:55 2024 +0100 Include .rodata size in avr-objdump -P mem-usage. PR 31687 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31704] [avr] Support avr-objdump -P avr-deviceinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=31704 --- Comment #2 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f65d4a2f81060e58d86616e8773fb0af38cab33b commit f65d4a2f81060e58d86616e8773fb0af38cab33b Author: Georg-Johann Lay Date: Mon May 20 12:12:10 2024 +0100 Let avr-objdump show .note.gnu.avr.deviceinfo PR 31704 -- You are receiving this mail because: You are on the CC list for the bug.
