[Bug gprofng/30006] Failure to build binutils-2.40 on i686
https://sourceware.org/bugzilla/show_bug.cgi?id=30006 --- Comment #4 from Satadru Pramanik --- Following the build failure with make -j 1: make[5]: Entering directory '/usr/local/tmp/crew/binutils.20230117084748.dir/binutils-2.40/build/gprofng/libcollector' /bin/bash ./libtool --tag=CC --mode=link i686-cros-linux-gnu-gcc -Wall -Wno-nonnull-compare -O2 -pipe -ffat-lto-objects -fPIC -fuse-ld=mold -flto -module -avoid-version -Wl,--version-script,../../../gprofng/libcollector/mapfile.intel-Linux -Wl,--no-as-needed -Wl,-lrt -Wl,-ldl -flto -o libgp-collector.la -rpath /usr/local/lib/gprofng libgp_collector_la-gethrtime.lo libgp_collector_la-dispatcher.lo libgp_collector_la-iolib.lo libgp_collector_la-mmaptrace.lo libgp_collector_la-memmgr.lo libgp_collector_la-tsd.lo libgp_collector_la-profile.lo libgp_collector_la-envmgmt.lo libgp_collector_la-linetrace.lo libgp_collector_la-libcol_hwcdrv.lo libgp_collector_la-libcol_hwcfuncs.lo libgp_collector_la-libcol-i386-dis.lo libgp_collector_la-hwprofile.lo libgp_collector_la-jprofile.lo libgp_collector_la-unwind.lo libgp_collector_la-libcol_util.lo libgp_collector_la-collector.lo libtool: link: i686-cros-linux-gnu-gcc -shared -fPIC -DPIC .libs/libgp_collector_la-gethrtime.o .libs/libgp_collector_la-dispatcher.o .libs/libgp_collector_la-iolib.o .libs/libgp_collector_la-mmaptrace.o .libs/libgp_collector_la-memmgr.o .libs/libgp_collector_la-tsd.o .libs/libgp_collector_la-profile.o .libs/libgp_collector_la-envmgmt.o .libs/libgp_collector_la-linetrace.o .libs/libgp_collector_la-libcol_hwcdrv.o .libs/libgp_collector_la-libcol_hwcfuncs.o .libs/libgp_collector_la-libcol-i386-dis.o .libs/libgp_collector_la-hwprofile.o .libs/libgp_collector_la-jprofile.o .libs/libgp_collector_la-unwind.o .libs/libgp_collector_la-libcol_util.o .libs/libgp_collector_la-collector.o -Wl,--version-script -Wl,../../../gprofng/libcollector/mapfile.intel-Linux -Wl,--no-as-needed -Wl,-lrt -Wl,-ldl -Wl,-soname -Wl,libgp-collector.so -o .libs/libgp-collector.so /usr/local/bin/ld: warning: using 'GLIBC_2.0' as version for 'dlopen' which is also named in version 'GLIBC_2.1' in script lto-wrapper: warning: using serial compilation of 3 LTRANS jobs lto-wrapper: note: see the '-flto' option documentation for more information /usr/local/bin/ld: warning: using 'GLIBC_2.0' as version for 'dlopen' which is also named in version 'GLIBC_2.1' in script /usr/local/bin/ld: error: /usr/local/tmp/ccDqCxMq.ltrans0.ltrans.o: multiple definition of 'dlopen' /usr/local/bin/ld: /usr/local/tmp/ccDqCxMq.ltrans0.ltrans.o: previous definition here collect2: error: ld returned 1 exit status make[5]: *** [Makefile:568: libgp-collector.la] Error 1 make[5]: Leaving directory '/usr/local/tmp/crew/binutils.20230117084748.dir/binutils-2.40/build/gprofng/libcollector' make[4]: *** [Makefile:479: all] Error 2 make[4]: Leaving directory '/usr/local/tmp/crew/binutils.20230117084748.dir/binutils-2.40/build/gprofng/libcollector' make[3]: *** [Makefile:472: all-recursive] Error 1 make[3]: Leaving directory '/usr/local/tmp/crew/binutils.20230117084748.dir/binutils-2.40/build/gprofng' make[2]: *** [Makefile:404: all] Error 2 make[2]: Leaving directory '/usr/local/tmp/crew/binutils.20230117084748.dir/binutils-2.40/build/gprofng' make[1]: *** [Makefile:7774: all-gprofng] Error 2 make[1]: Leaving directory '/usr/local/tmp/crew/binutils.20230117084748.dir/binutils-2.40/build' make: *** [Makefile:1005: all] Error 2 There was a build error. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/30006] Failure to build binutils-2.40 on i686
https://sourceware.org/bugzilla/show_bug.cgi?id=30006 --- Comment #5 from Satadru Pramanik --- (This system uses Glibc 2.23.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 Jan-Benedict Glaw changed: What|Removed |Added CC||jbg...@lug-owl.de -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 --- Comment #5 from Jan-Benedict Glaw --- I do regular builds (own build strategy and a hacked build-many-glibcs.py to allow for HEAD versions) and the later started to fail since this commit: /bin/bash ../libtool --tag=CXX --mode=link g++ -Wall -pthread -Wno-switch -g -O2 -o gp-archive gp-archive.o ArchiveExp.o libgprofng.la -L../../zlib -lz libtool: link: g++ -Wall -pthread -Wno-switch -g -O2 -o gp-archive gp-archive.o ArchiveExp.o ./.libs/libgprofng.a /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/opcodes/.libs/libopcodes.a -lpthread -ldl -L/var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/zlib -lz -pthread /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/opcodes/.libs/libopcodes.a(i386-dis.o): warning: relocation against `_sch_istable' in read-only section `.text' /usr/bin/ld: ./.libs/libgprofng.a(Elf.o): in function `Elf::elf_init()': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/Elf.cc:142: undefined reference to `bfd_init' /usr/bin/ld: ./.libs/libgprofng.a(Elf.o): in function `Elf::~Elf()': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/Elf.cc:274: undefined reference to `bfd_close' /usr/bin/ld: ./.libs/libgprofng.a(Elf.o): in function `Elf::Elf(char*)': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/Elf.cc:159: undefined reference to `bfd_openr' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/Elf.cc:165: undefined reference to `bfd_check_format' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/Elf.cc:175: undefined reference to `bfd_close' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/Elf.cc:167: undefined reference to `bfd_close' /usr/bin/ld: ./.libs/libgprofng.a(Function.o): in function `Function::set_name(char*)': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/Function.cc:218: undefined reference to `cplus_demangle' /usr/bin/ld: ./.libs/libgprofng.a(CompCom.o): in function `CompComment::get_demangle_name(char*)': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/CompCom.cc:109: undefined reference to `cplus_demangle' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/CompCom.cc:109: undefined reference to `cplus_demangle' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/CompCom.cc:109: undefined reference to `cplus_demangle' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/CompCom.cc:109: undefined reference to `cplus_demangle' /usr/bin/ld: ./.libs/libgprofng.a(dbe_collctrl.o): in function `Coll_Ctrl::find_sig(char const*)': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/gprofng/src/collctrl.cc:2345: undefined reference to `strtosigno' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/opcodes/.libs/libopcodes.a(i386-dis.o): in function `i386_dis_printf': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/opcodes/i386-dis.c:9615: undefined reference to `_sch_istable' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/opcodes/.libs/libopcodes.a(i386-dis.o): in function `putop': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/opcodes/i386-dis.c:10645: undefined reference to `_sch_istable' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/opcodes/i386-dis.c:10778: undefined reference to `_sch_istable' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/opcodes/.libs/libopcodes.a(disassemble.o): in function `remove_whitespace_and_extra_commas': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/opcodes/disassemble.c:821: undefined reference to `_sch_istable' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/opcodes/disassemble.c:829: undefined reference to `_sch_istable' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/opcodes/.libs/libopcodes.a(disassemble.o): in function `opcodes_assert': /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/opcodes/disassemble.c:876: undefined reference to `_bfd_error_handler' /usr/bin/ld: /var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/src/binutils/opcodes/disassemble.c:877: undefined reference to `_bfd_error_handler' /usr/bin/ld: warning: creating DT_TEXTREL in a PIE collect2: error: ld returned 1 exit status make[6]: *** [Makefile:724: gp-archive] Error 1 make[6]: Leaving directory '/var/lib/laminar/run/glibcbot-x86_64-linux-gnu/5/build/compilers/x86_64-linux-gnu/binutils/gprofng/sr
[Bug gprofng/29987] bfd/archive.c:1447: undefined reference to `filename_ncmp'
https://sourceware.org/bugzilla/show_bug.cgi?id=29987 --- Comment #6 from Jan-Benedict Glaw --- Just ftr: The build-many-glibcs.py script does the equivalent of: /var/cache/git/binutils-gdb/configure '--prefix=/tmp/b/i' \ '--build=x86_64-pc-linux-gnu' \ '--host=x86_64-pc-linux-gnu' \ '--target=x86_64-glibc-linux-gnu' \ '--with-sysroot=/tmp/b/i/sysroot' \ --disable-gdb \ --disable-gdbserver \ --disable-libdecnumber \ --disable-readline \ --disable-sim make (Pathes shortened here, but that's a working example.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13671] gld creates i386 relocations not supported by Solaris ld.so.1
https://sourceware.org/bugzilla/show_bug.cgi?id=13671 Rainer Orth changed: What|Removed |Added URL||https://sourceware.org/pipe ||rmail/binutils/2023-January ||/125706.html --- Comment #32 from Rainer Orth --- (In reply to H.J. Lu from comment #31) > (In reply to Rainer Orth from comment #29) > > Created attachment 14590 [details] > > Augmented^2 patch > > LGTM. Please send it to the binutils mailing list. Thanks. Done now. Thanks a lot for the fix and your patience. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=29998 --- Comment #6 from Nick Clifton --- (In reply to Jan Janssen from comment #5) Hi Jan, Hmm, I am beginning to suspect the libtlo_plugin (from gcc, not the binutils) as the cause of this problem... > /usr/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld > -plugin /usr/lib/gcc/x86_64-w64-mingw32/12.2.0/liblto_plugin.so > -plugin-opt=/usr/lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper > -plugin-opt=-fresolution=/tmp/ccJFF0sj.res -m i386pep -Bdynamic -o test.exe > -L/usr/lib/gcc/x86_64-w64-mingw32/12.2.0 > -L/usr/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib/. > ./lib > -L/usr/lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/lib > test2.obj libtest.a -lgcc > collect2: fatal error: ld terminated with signal 11 [Segmentation fault], > core dumped I am stuck here because I do not have /usr/lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper installed (and just using a dummy empty file does not work). As a quick test, if you have both gcc 12 and gcc 10 installed, does editing that command line above and using the gcc 10 plugin and/or gcc 10 lto-wrapper script make the link work ? Also - does adding "-plugin-opt=-debug" to the command line produce any more helpful output ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30004] LD --exclude-all-symbols generates export table
https://sourceware.org/bugzilla/show_bug.cgi?id=30004 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Assignee|unassigned at sourceware dot org |nickc at redhat dot com Ever confirmed|0 |1 Last reconfirmed||2023-01-17 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Nick Clifton --- Created attachment 14604 --> https://sourceware.org/bugzilla/attachment.cgi?id=14604&action=edit Proposed patch Hi Pali, Please could you try out this patch and let me know if it works for you ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30005] __declspec(code_seg("segname")) does not work
https://sourceware.org/bugzilla/show_bug.cgi?id=30005 Nick Clifton changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Pali, Sorry, but you need to refile this bug with gcc, rather than us, as it is gcc that interprets the __declspec() directives and converts them into assembler commands. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30013] New: [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping
https://sourceware.org/bugzilla/show_bug.cgi?id=30013 Bug ID: 30013 Summary: [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping Product: binutils Version: 2.40 Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: ro at gcc dot gnu.org CC: nick.alcock at oracle dot com Target Milestone: --- When I recently upgraded my self-compiled version used for gcc bootstraps from 2.39 to 2.40, a couple of testsuite regressions occured: +FAIL: gcc.dg/debug/20020220-1.c -gctf (test for excess errors) Excess errors: Assertion failed: one_type != two_type, file /vol/src/gnu/binutils/binutils-2.40/libctf/ctf-dedup.c, line 2342, function sort_output_mapping collect2: fatal error: ld terminated with signal 6 [Abort] +FAIL: gcc.dg/debug/20020220-1.c -gctf execution test +FAIL: gcc.dg/debug/20050907-1.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr36690-3.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr36690-3.c -gctf execution test +FAIL: gcc.dg/debug/pr37616.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr37616.c -gctf execution test +FAIL: gcc.dg/debug/pr41893-1.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr49032.c -gctf (test for excess errors) +FAIL: gcc.dg/debug/pr65771.c -gctf (test for excess errors) They happen on Solaris/sparc and x86, 32 and 64-bit. It turns out that the assertion failure occurs when qsort_r is missing from libc (as on Solaris 11.3, unlike Solaris 11.4). However, there's nothing Solaris-specific here: if I disable qsort_r in config.status on Linux/i686 --- config.status.dist 2023-01-17 16:51:27.241499000 +0100 +++ config.status 2023-01-17 16:51:42.380104000 +0100 @@ -820,2 +820,2 @@ -S["NEED_CTF_QSORT_R_FALSE"]="" -S["NEED_CTF_QSORT_R_TRUE"]="#" +S["NEED_CTF_QSORT_R_FALSE"]="#" +S["NEED_CTF_QSORT_R_TRUE"]="" @@ -1050,2 +1049,0 @@ -D["HAVE_QSORT_R"]=" 1" -D["HAVE_QSORT_R_ARG_LAST"]=" 1" (there sems to be no way to do this otherwise, e.g. by presetting autoconf cache variables), I get exactly the same failure, so there seems to be something wrong with ctf-qsort_r.c. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=29998 --- Comment #7 from Jan Janssen --- > I am stuck here because I do not have > /usr/lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper installed (and just using > a dummy empty file does not work). It's as easy as: $ deboostrap --include=gcc-12,gcc-10,gcc-mingw-w64-x86-64 sid debian-unstable $ systemd-nspawn -M debian-unstable To get the same env as me when I tried reproducing on a different distro. Also, on debian the wrapper is located in /usr/lib/gcc/x86_64-w64-mingw32/12-win32/lto-wrapper > As a quick test, if you have both gcc 12 and gcc 10 installed, does editing > that command line above and using the gcc 10 plugin and/or gcc 10 lto-wrapper > script make the link work ? This is rather tricky as there is only one version of mingw-gcc in distros so I used the regular gcc (if it helps)… $ COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_GCC_OPTIONS="-flto=auto -nostdlib -o test.exe -mtune=generic -march=x86-64 -dumpdir test." /usr/bin/x86_64-w64-mingw32-ld -plugin /usr/lib/gcc/x86_64-linux-gnu/10/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper -plugin-opt=-fresolution=/tmp/ccl4X7GI.res -m i386pep -Bdynamic -o test.exe -L/usr/lib/gcc/x86_64-w64-mingw32/12-win32 -L/usr/lib/gcc/x86_64-w64-mingw32/12-win32/../../../../x86_64-w64-mingw32/lib test2.obj libtest.a -lgcc Segmentation fault (core dumped) > Also - does adding "-plugin-opt=-debug" to the command line produce any more > helpful output ? /usr/lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper -fresolution=/tmp/cc9yab77.res -flinker-output=exec test2.obj test1.obj /usr/lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper @test.lto_wrapper_args (Same output with successful mingw-gcc10) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29998] ld terminated with signal 11 [Segmentation fault] under mingw with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=29998 --- Comment #8 from Jan Janssen --- I rebuilt mingw-w64-binutils with debug info and managed to get a backtrace (this if on arch): Thread 1 (Thread 0x77db1740 (LWP 84627) "ld"): #0 generate_reloc (abfd=0x557f8a40, info=0x557bbe20 ) at /usr/src/debug/mingw-w64-binutils/binutils-2.38/ld/pe-dll.c:1538 sec_vma = 5368717312 symbols = 0x5585f940 relocs = 0x55803ad0 relsize = 8 nrelocs = 0 reloc_data = 0x5586dc50 total_relocs = 0 i = 0 sec_page = 18446744073709551615 page_ptr = 93824995009440 page_count = 93824995010968 bi = 3 b = 0x55853c10 s = 0x55861e08 #1 0x555d2c90 in pep_exe_fill_sections (abfd=0x557f8a40, info=0x557bbe20 ) at /usr/src/debug/mingw-w64-binutils/binutils-2.38/ld/pe-dll.c:3640 No locals. #2 0x555d2bd6 in pep_dll_fill_sections (abfd=0x557f8a40, info=0x557bbe20 ) at /usr/src/debug/mingw-w64-binutils/binutils-2.38/ld/pe-dll.c:3621 No locals. #3 0x555c0d4c in gld_i386pep_finish () at ei386pep.c:1773 No locals. #4 0x555b50ed in ldemul_finish () at /usr/src/debug/mingw-w64-binutils/binutils-2.38/ld/ldemul.c:101 No locals. #5 0x555a98b9 in lang_process () at /usr/src/debug/mingw-w64-binutils/binutils-2.38/ld/ldlang.c:8295 No locals. #6 0x555ae1cf in main (argc=17, argv=0x7fffdf88) at /usr/src/debug/mingw-w64-binutils/binutils-2.38/ld/ldmain.c:497 emulation = 0x7fffe4a3 "i386pep" start_time = 13700 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libsframe/30014] New: FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe
https://sourceware.org/bugzilla/show_bug.cgi?id=30014 Bug ID: 30014 Summary: FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libsframe Assignee: indu.bhagat at oracle dot com Reporter: thiago at kde dot org Target Milestone: --- # make install-strip-host /bin/sh ./mkinstalldirs /usr/local /usr/local make[1]: Entering directory `/build/binutils-2.40/bfd' if test -z 'strip'; then \ make INSTALL_PROGRAM="/bin/sh /build/binutils-2.40/install-sh -c -s" \ install_sh_PROGRAM="/bin/sh /build/binutils-2.40/install-sh -c -s" INSTALL_STRIP_FLAG=-s \ install; \ else \ make INSTALL_PROGRAM="/bin/sh /build/binutils-2.40/install-sh -c -s" \ install_sh_PROGRAM="/bin/sh /build/binutils-2.40/install-sh -c -s" INSTALL_STRIP_FLAG=-s \ "INSTALL_PROGRAM_ENV=STRIPPROG='strip'" install; \ fi make[2]: Entering directory `/build/binutils-2.40/bfd' make install-recursive make[3]: Entering directory `/build/binutils-2.40/bfd' Making install in po make[4]: Entering directory `/build/binutils-2.40/bfd/po' if test -r .././../mkinstalldirs; then \ .././../mkinstalldirs /usr/local/share; \ else \ ../mkinstalldirs /usr/local/share; \ fi [...] make[5]: Entering directory `/build/binutils-2.40/bfd' make[5]: Nothing to be done for `install-exec-am'. /usr/bin/mkdir -p '/usr/include' /usr/bin/install -c -m 644 bfd.h ./../include/ansidecl.h ./../include/symcat.h ./../include/diagnostics.h ./../include/bfdlink.h ./../include/plugin-api.h '/usr/include' /usr/bin/mkdir -p '/usr/local/lib' /bin/sh ./libtool --mode=install /usr/bin/install -c -s libbfd.la '/usr/local/lib' libtool: install: warning: relinking `libbfd.la' libtool: install: (cd /build/binutils-2.40/bfd; /bin/sh /build/binutils-2.40/bfd/libtool --silent --tag CC --mode=relink gcc -std=gnu99 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -release 2.40 -o libbfd.la -rpath /usr/local/lib archive.lo archures.lo bfd.lo bfdio.lo bfdwin.lo cache.lo coff-bfd.lo compress.lo corefile.lo elf-properties.lo format.lo hash.lo init.lo libbfd.lo linker.lo merge.lo opncls.lo reloc.lo section.lo simple.lo stab-syms.lo stabs.lo syms.lo targets.lo binary.lo ihex.lo srec.lo tekhex.lo verilog.lo elf64-x86-64.lo elfxx-x86.lo elf-ifunc.lo elf-vxworks.lo elf64.lo elf.lo elflink.lo elf-attrs.lo elf-strtab.lo elf-eh-frame.lo elf-sframe.lo dwarf1.lo dwarf2.lo elf32-i386.lo elf32.lo pei-i386.lo peigen.lo cofflink.lo coffgen.lo pe-x86_64.lo pex64igen.lo pei-x86_64.lo elf64-gen.lo elf32-gen.lo plugin.lo cpu-i386.lo cpu-iamcu.lo archive64.lo -L/build/binutils-2.40/bfd/../libiberty/pic -liberty -Wl,-lc,--as-needed,-lm,--no-as-needed -ldl -lz ../libsframe/libsframe.la -ldl ) /usr/bin/ld: cannot find -lsframe collect2: error: ld returned 1 exit status libtool: install: error: relink `libbfd.la' with the above command before installing it make[5]: *** [install-bfdlibLTLIBRARIES] Error 1 make[5]: Leaving directory `/build/binutils-2.40/bfd' make[4]: *** [install-am] Error 2 make[4]: Leaving directory `/build/binutils-2.40/bfd' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/build/binutils-2.40/bfd' make[2]: *** [install] Error 2 make[2]: Leaving directory `/build/binutils-2.40/bfd' make[1]: *** [install-strip] Error 2 make[1]: Leaving directory `/build/binutils-2.40/bfd' make: *** [install-strip-bfd] Error 2 I don't know why libtool wants to relink and that's probably the root of the problem. I don't know if it relinked in 2.39 too, but the problem is that now it attempt to relink and fails. Do note that the command-line has ../libsframe/libsframe.la and that file does exist, and so do the libraries inside libsframe/.libs. However, libsframe hasn't been installed to /usr/local yet. From the Makefile: .PHONY: install-strip-host install-strip-host: \ maybe-install-strip-bfd \ [... everything else ...] maybe-install-strip-libsframe I don't know if the order matters and, if it does, why the build system didn't put it in the right order in the first place. Configure: ./configure \ --includedir=/usr/include \ --with-lib-path=/usr/lib64:/usr/lib \ --enable-shared --disable-static \ --target=x86_64-generic-linux \ --build=x86_64-generic-linux \ --enable-targets=x86_64-linux \ --enable-deterministic-archives \ --enable-lto \
[Bug binutils/30016] New: strip/objcopy should do atomic renames
https://sourceware.org/bugzilla/show_bug.cgi?id=30016
Bug ID: 30016
Summary: strip/objcopy should do atomic renames
Product: binutils
Version: 2.40
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: thiago at kde dot org
Target Milestone: ---
I noticed this while building binutils itself because, after ./binutils got
installed, the installed strip was in $PATH and that caused errors later on.
strace shows that strip/objcopy create a temporary file to write contents to,
but later truncate the target file and do a manual copy of everything:
$ strace strip toolname
newfstatat(AT_FDCWD, "toolname", {st_mode=S_IFREG|0755, st_size=1772072, ...},
0) = 0
openat(AT_FDCWD, "stA2UbOD", O_RDWR|O_CREAT|O_EXCL, 0600) = 3//
creates temporary file
dup(3) = 4
newfstatat(AT_FDCWD, "toolname", {st_mode=S_IFREG|0755, st_size=1772072, ...},
0) = 0
openat(AT_FDCWD, "toolname", O_RDONLY) = 5 //
opens source file
fcntl(5, F_GETFD) = 0
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=512*1024}) = 0
newfstatat(5, "", {st_mode=S_IFREG|0755, st_size=27183920, ...}, AT_EMPTY_PATH)
= 0
newfstatat(5, "", {st_mode=S_IFREG|0755, st_size=27183920, ...}, AT_EMPTY_PATH)
= 0
[lots of read, lseek and stat]
mmap(NULL, 978944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x55b46f311000
munmap(0x55b46f311000, 978944) = 0
brk(0x55b470f37000) = 0x55b470f37000
[read,lseek and writes of different sizes here]
close(3)= 0
newfstatat(AT_FDCWD, "stA2UbOD", {st_mode=S_IFREG|0600, st_size=1772072, ...},
0) = 0 // stat() on the temporary file instead of fstat() on the still-open
file descriptor 4
umask(000) = 022
umask(022) = 000
chmod("stA2UbOD", 0711) = 0 // unnecessary chmod() on
the temporary file; fchmod() preferred
close(5)= 0
openat(AT_FDCWD, "toolname", O_WRONLY|O_TRUNC) = 3 // reopens the
output file, truncating
[read & write of the exact same size]
read(4, "", 8192) = 0
fchmod(3, 0100755) = 0
close(4)= 0
close(3)= 0
unlink("stA2UbOD") = 0
The last block is wasteful and problematic. objcopy/strip should have simply
renamed the temporary file "stA2UbOD" to the target "toolname" instead of
copying 1.7 MB.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libsframe/30014] FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe
https://sourceware.org/bugzilla/show_bug.cgi?id=30014 --- Comment #1 from Indu Bhagat --- Created attachment 14605 --> https://sourceware.org/bugzilla/attachment.cgi?id=14605&action=edit Proposed fix for pr 30014 Proposed fix. Will test this patch on my end. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libsframe/30014] FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe
https://sourceware.org/bugzilla/show_bug.cgi?id=30014 --- Comment #2 from Indu Bhagat --- Thanks for reporting this issue and providing all the details. Very helpful. The issue seems to be that the applicable dependency (install-strip-bfd: maybe-install-strip-libsframe) was missing. As for libtool relinking at install time, that's expected. Similar is done for libopcodes.la, libctf.la etc. at install time. The relinking, as far as my basic understanding of libtool goes, is done to ensure an updated rpath in the installed libraries. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30016] strip/objcopy should do atomic renames
https://sourceware.org/bugzilla/show_bug.cgi?id=30016 --- Comment #1 from Andreas Schwab --- This is deliberate. A rename requires careful duplication of the attributes of the target file, which is difficult to get right. See PR27456. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30016] strip/objcopy should do atomic renames
https://sourceware.org/bugzilla/show_bug.cgi?id=30016 --- Comment #2 from Thiago Macieira --- (In reply to Andreas Schwab from comment #1) > This is deliberate. A rename requires careful duplication of the attributes > of the target file, which is difficult to get right. See PR27456. Are you sure of the number? That's a build failure on Windows. Anyway, I understand some internal details of the file may depend on the file name (on some architectures), but why can't the correct content be written to a temporary file instead of the final one? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29521] [docs] man pages are not in the release tarball
https://sourceware.org/bugzilla/show_bug.cgi?id=29521 --- Comment #3 from Ruud van der Pas --- Unfortunately we did not get to address this before 2.40 was released, but we are actively looking into a solution. We plan to either embed the man page texts in .texi files (or perhaps a single file), or we see if help2man can be endorsed by binutils. The latter will not be in time for 2.40 though and perhaps an interim approach is needed for this situation. Either way, we want to resolve this asap now. -- You are receiving this mail because: You are on the CC list for the bug.
