[Bug libdw/32929] 0.193 regression: dwarf_srclang_check: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory
https://sourceware.org/bugzilla/show_bug.cgi?id=32929 --- Comment #2 from Sergei Trofimovich --- Yes, the change fixes the test failure and all tests pass now locally. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/32929] New: 0.193 regression: dwarf_srclang_check: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory
https://sourceware.org/bugzilla/show_bug.cgi?id=32929 Bug ID: 32929 Summary: 0.193 regression: dwarf_srclang_check: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: slyich at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- When attempted to package new elfutils-0.193 I got one new test failure on the system without elfutils installed yet as: make check-TESTS FAIL: dwarf_srclang_check == elfutils 0.193: libdw/test-suite.log == # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 System information (uname -a): Linux 6.14.4 #1-NixOS SMP PREEMPT_DYNAMIC Fri Apr 25 08:51:21 UTC 2025 x86_64 .. contents:: :depth: 2 FAIL: dwarf_srclang_check = ./dwarf_srclang_check: error while loading shared libraries: libelf.so.1: cannot open shared object file: No such file or directory FAIL dwarf_srclang_check (exit status: 127) Should dwarf_srclang_check add an RPATH to the locally built library? Bisect points at: commit 4d50c9e68808cbdd22dd70c26482ec010aefcbbf Author: Mark Wielaard Date: Wed Apr 2 13:35:31 2025 +0200 libdw: Add Nim language and dwarf_srclang tests -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/33103] elfutils fails in-tree build due to ./stack binary #included via
https://sourceware.org/bugzilla/show_bug.cgi?id=33103 --- Comment #2 from Sergei Trofimovich --- I don't think c++ standard guarantees exact transitive headers included by other headers. I think the difference is the implementation detail of libstdc++ vs libc++. libstdc++'s does not include (and also does not get enabled without -std=c++20): - https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/format;h=46bd5d5ee6a0e72520776ea21610e84ef5c6aca9;hb=HEAD#l45 - https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/ostream;h=3a0a0d35df1d69f620bfbe0e1d94a790904193f2;hb=HEAD#l44 libc++'s does include it (and only does it before -std=c++20): - https://github.com/llvm/llvm-project/blob/08b8d467d4253373e77a075c03e25281dee8ad15/libcxx/include/format#L252 - https://github.com/llvm/llvm-project/blob/08b8d467d4253373e77a075c03e25281dee8ad15/libcxx/include/ostream#L201 Both implementations slowly clean their header structure up going forward. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/33103] New: elfutils fails in-tree build due to ./stack binary #included via
https://sourceware.org/bugzilla/show_bug.cgi?id=33103 Bug ID: 33103 Summary: elfutils fails in-tree build due to ./stack binary #included via Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: slyich at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- https://sourceware.org/pipermail/elfutils-devel/2024q3/007281.html has a bit of prior discussion and even a has fix submitted (https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=b426c4db31e7c80d4262abdd845d2ece0c9a841c). Unfortunately the fix still fails in some scenarios: in-tree libc++ builds. The simplest way to reproduce the build on `gcc` failure is to add `#include ` into `src/srcfiles.cxx`: --- a/src/srcfiles.cxx +++ b/src/srcfiles.cxx @@ -40,6 +40,7 @@ #include #include #include +#include /* simulate transitive include on libc++ */ #ifdef ENABLE_LIBDEBUGINFOD #include "debuginfod.h" Now we can fail the build on `gcc`: $ autoreconf -ifv && ./configure --enable-maintainer-mode && make && make check ... Making all in src CXX srcfiles.o In file included from srcfiles.cxx:43: ./stack:1:1: error: stray '\177' in program 1 | ELF< This happens because src/Makefile still contains `-I .`: srcdir = . ... AM_CPPFLAGS = -iquote . -I$(srcdir) ... As a workaround nixpkgs now uses out-of-tree builds as: mkdir build-tree cd build-tree ../configure ... But it would be nice to fix the collision for in-tree builds. For libc++ build failure `` is included transitively via : In file included from srcfiles.cxx:50: In file included from /nix/store/7mk6c0p1jvxm3vq2my5swi5jlidby1h7-libcxx-x86_64-unknown-linux-gnu-19.1.7-dev/include/c++/v1/iostream:43: In file included from /nix/store/7mk6c0p1jvxm3vq2my5swi5jlidby1h7-libcxx-x86_64-unknown-linux-gnu-19.1.7-dev/include/c++/v1/istream:1367: In file included from /nix/store/7mk6c0p1jvxm3vq2my5swi5jlidby1h7-libcxx-x86_64-unknown-linux-gnu-19.1.7-dev/include/c++/v1/ostream:194: In file included from /nix/store/7mk6c0p1jvxm3vq2my5swi5jlidby1h7-libcxx-x86_64-unknown-linux-gnu-19.1.7-dev/include/c++/v1/format:246: ./stack:1:1: error: expected unqualified-id 1 | ELF... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/33103] elfutils fails in-tree build due to ./stack binary #included via
https://sourceware.org/bugzilla/show_bug.cgi?id=33103
--- Comment #4 from Sergei Trofimovich ---
(In reply to Mark Wielaard from comment #3)
> I don't understand why this is only a problem with srcdir == builddir.
AFAIU the difference in in-tree/out-of-tree is the following:
in-tree:
- builder process is in src/
- src/ contains freshly built 'stack' binary
- clang is ran as 'clang++ -iquote . -I . srcfiles.cxx'
- is looked up from '-I .' and finds ./stack ELF
out-of-tree:
- builder process is in build-tree/src/
- build-tree/src/ contains freshly built 'stack' binary
- clang is ran as 'clang++ -iquote . -I ../../src srcfiles.cxx'
- is looked up from '-I ../../src' and does not find ./stack (as
it's in current ./stack build tree, source tree is clean)
> But maybe we can extend the original solution to use -iquote for srcdir. And
> only have -I for lib and the top builddir (for )?
>
> Does the following work for you?
>
> diff --git a/config/eu.am b/config/eu.am
> index 5157a34ee552..1361044804f5 100644
> --- a/config/eu.am
> +++ b/config/eu.am
> @@ -31,7 +31,7 @@
> ##
>
> DEFS = -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"${localedir}"'
> -AM_CPPFLAGS = -iquote . -I$(srcdir) -I$(top_srcdir)/lib -I..
> +AM_CPPFLAGS = -iquote. -iquote$(srcdir) -I$(top_srcdir)/lib
> -I$(abs_top_builddir)
>
> # Drop the 'u' flag that automake adds by default. It is incompatible
> # with deterministic archives.
> diff --git a/libdw/libdwP.h b/libdw/libdwP.h
> index 25d53d31c7c8..b77db1423fe0 100644
> --- a/libdw/libdwP.h
> +++ b/libdw/libdwP.h
> @@ -32,8 +32,8 @@
> #include
> #include
>
> -#include
> -#include
> +#include "libdw.h"
> +#include "dwarf.h"
> #include "eu-search.h"
Yes, I confirm that fixes build failure for my in-tree clang setup.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/29450] New: run-low_high_pc.sh fails on i386 against binutils-2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29450 Bug ID: 29450 Summary: run-low_high_pc.sh fails on i386 against binutils-2.39 Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: slyich at gmail dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- binutils-2.39 is out: https://sourceware.org/pipermail/binutils/2022-August/122246.html I tried to package it in nixpkgs and found a few build or test failures. elfutils-0.187 and elfutils from git both fail run-low_high_pc.sh as: FAIL: run-low_high_pc.sh [b] main.c [2d] main [b] ../sysdeps/i386/start.S [26] _start [40] ../sysdeps/x86/abi-note.c [b52] init.c [b8e] static-reloc.c [2dba] _dl_relocate_static_pie [2dd8] ../sysdeps/i386/crti.S [2def] _init lowpc: 8049000, highpc: 8049000lx ../sysdeps/i386/crti.S: [2def] '_init' highpc <= lowpc FAIL run-low_high_pc.sh (exit status: 255) Extra `lx` prefix looks minor. lowpc == highpc looks real. gdb somehow manages to detect the PC range for _init. Not sure which of tested files is that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29450] run-low_high_pc.sh fails on i386 against binutils-2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29450 --- Comment #1 from Sergei Trofimovich --- Created attachment 14257 --> https://sourceware.org/bugzilla/attachment.cgi?id=14257&action=edit low_high_pc Attaching the binary itself. It was a failing selftest: $ LD_LIBRARY_PATH=$PWD/libdw:$PWD/libelf tests/low_high_pc -e tests/low_high_pc [b] ../sysdeps/i386/start.S [26] _start [40] ../sysdeps/x86/abi-note.c [b52] init.c [b8e] static-reloc.c [2dba] _dl_relocate_static_pie [2dd8] ../sysdeps/i386/crti.S [2def] _init lowpc: 8049000, highpc: 8049000 ../sysdeps/i386/crti.S: [2def] '_init' highpc <= lowpc gdb somehow knows the size of the _init: $ gdb /tmp/low_high_pc Reading symbols from /tmp/low_high_pc... (gdb) disassemble _init Dump of assembler code for function _init: 0x08049000 <+0>: endbr32 0x08049004 <+4>: push %ebx 0x08049005 <+5>: sub$0x8,%esp 0x08049008 <+8>: call 0x8049400 <__x86.get_pc_thunk.bx> 0x0804900d <+13>:add$0x2f93,%ebx 0x08049013 <+19>:mov0x5c(%ebx),%eax 0x08049019 <+25>:test %eax,%eax 0x0804901b <+27>:je 0x804901f <_init+31> 0x0804901d <+29>:call *%eax 0x0804901f <+31>:add$0x8,%esp 0x08049022 <+34>:pop%ebx 0x08049023 <+35>:ret End of assembler dump. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29450] run-low_high_pc.sh fails on i386 against binutils-2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29450 --- Comment #2 from Sergei Trofimovich --- Could it be that it's a mild `crti.o` corruption by new binutils? "MIPS assembler" does not sound right. ``` $ readelf -aW crti.o --debug-dump ... Contents of the .debug_info section: Compilation Unit @ offset 0x0: Length:0x49 (32-bit) Version: 2 Abbrev Offset: 0x0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : (data4) 0x0 <10> DW_AT_ranges : (data4) 0x0 <14> DW_AT_name: (strp) (offset: 0x0): ../sysdeps/i386/crti.S <18> DW_AT_comp_dir: (strp) (offset: 0x17): /build/glibc-2.35/csu <1c> DW_AT_producer: (strp) (offset: 0x2d): GNU AS 2.39 <20> DW_AT_language: (data2) 32769(MIPS assembler) <1><22>: Abbrev Number: 2 (DW_TAG_subprogram) <23> DW_AT_name: (strp) (offset: 0x39): _init <27> DW_AT_external: (flag) 1 <28> DW_AT_low_pc : (addr) 0x0 <2c> DW_AT_high_pc : (addr) 0x0 <1><30>: Abbrev Number: 2 (DW_TAG_subprogram) <31> DW_AT_name: (strp) (offset: 0x3f): __x86.get_pc_thunk.bx <35> DW_AT_external: (flag) 1 <36> DW_AT_low_pc : (addr) 0x0 <3a> DW_AT_high_pc : (addr) 0x4 <1><3e>: Abbrev Number: 2 (DW_TAG_subprogram) <3f> DW_AT_name: (strp) (offset: 0x55): _fini <43> DW_AT_external: (flag) 1 <44> DW_AT_low_pc : (addr) 0x0 <48> DW_AT_high_pc : (addr) 0x0 <1><4c>: Abbrev Number: 0 ... ``` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29450] run-low_high_pc.sh fails on i386 against binutils-2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29450 --- Comment #3 from Sergei Trofimovich --- gas-2.39 started adding 0-sized DIE for function without a .size marking: $ cat crti.S.S .section .init,"ax",@progbits .p2align 2 .globl _init .hidden _init .type _init, @function _init: .section .text.__x86.get_pc_thunk.bx,"axG",@progbits,__x86.get_pc_thunk.bx,comdat .globl __x86.get_pc_thunk.bx .hidden __x86.get_pc_thunk.bx .p2align 4 .type __x86.get_pc_thunk.bx,@function __x86.get_pc_thunk.bx: ud2 .size __x86.get_pc_thunk.bx, . - __x86.get_pc_thunk.bx .previous ud2 $ as-2.39 --gdwarf2 --32 -o crti.o crti.S.S $ readelf -aW --debug-dump crti.o <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : (data4) 0x0 <10> DW_AT_ranges : (data4) 0x0 <14> DW_AT_name: (strp) (offset: 0x0): crti.S.S <18> DW_AT_comp_dir: (strp) (offset: 0x9): /home/slyfox/dev/bugs/binutils-2.39-crti-size/delta <1c> DW_AT_producer: (strp) (offset: 0x3d): GNU AS 2.39 <20> DW_AT_language: (data2) 32769(MIPS assembler) <1><22>: Abbrev Number: 2 (DW_TAG_subprogram) <23> DW_AT_name: (strp) (offset: 0x49): _init <27> DW_AT_external: (flag) 1 <28> DW_AT_low_pc : (addr) 0x0 <2c> DW_AT_high_pc : (addr) 0x0 <1><30>: Abbrev Number: 2 (DW_TAG_subprogram) <31> DW_AT_name: (strp) (offset: 0x4f): __x86.get_pc_thunk.bx <35> DW_AT_external: (flag) 1 <36> DW_AT_low_pc : (addr) 0x0 <3a> DW_AT_high_pc : (addr) 0x2 <1><3e>: Abbrev Number: 0 $ as-2.38 --gdwarf2 --32 -o crti.o crti.S.S $ readelf -aW --debug-dump crti.o <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_stmt_list : (data4) 0x0 <10> DW_AT_ranges : (data4) 0x0 <14> DW_AT_name: (strp) (offset: 0x0): crti.S.S <18> DW_AT_comp_dir: (strp) (offset: 0x9): /home/slyfox/dev/bugs/binutils-2.39-crti-size/delta <1c> DW_AT_producer: (strp) (offset: 0x3d): GNU AS 2.38 <20> DW_AT_language: (data2) 32769(MIPS assembler) Not sure if it's a discrepancy in binutils. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29450] run-low_high_pc.sh fails on i386 against binutils-2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29450 --- Comment #4 from Sergei Trofimovich --- Filed https://sourceware.org/PR29451 against gas. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29450] run-low_high_pc.sh fails on i386 against binutils-2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29450 Sergei Trofimovich changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29451 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/29450] run-low_high_pc.sh fails on i386 against binutils-2.39
https://sourceware.org/bugzilla/show_bug.cgi?id=29450 Sergei Trofimovich changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Sergei Trofimovich --- Yeah. The gas fix fixed elfutils test suite for me. Let's mark it RESOLVED/MOVED. -- You are receiving this mail because: You are on the CC list for the bug.
