[Bug general/31439] New: error: undefined reference to '__dwarf_get_units_internal'
https://sourceware.org/bugzilla/show_bug.cgi?id=31439 Bug ID: 31439 Summary: error: undefined reference to '__dwarf_get_units_internal' Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: rudi at heitbaum dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- When cross-compiling 0.191 as target if fails linking with CCLD readelf readelf.o:readelf.c:function str_offsets_base_off:(.text+0x804e): error: undefined reference to '__dwarf_get_units_internal' collect2: error: ld returned 1 exit status Full output: -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/31439] error: undefined reference to '__dwarf_get_units_internal'
https://sourceware.org/bugzilla/show_bug.cgi?id=31439 rudi at heitbaum dot com changed: What|Removed |Added Host||x86_64 Target||x86_64 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/31439] error: undefined reference to '__dwarf_get_units_internal'
https://sourceware.org/bugzilla/show_bug.cgi?id=31439
--- Comment #2 from rudi at heitbaum dot com ---
(In reply to Mark Wielaard from comment #1)
> I don't fully understand how you are building, and I cannot replicate, but
> it seems something goes wrong with readelf.c using the libdwP.h "internals"
> header. Does the following patch help?
>
> diff --git a/libdw/libdwP.h b/libdw/libdwP.h
> index 8b2f06fa5937..c1c84ed3567d 100644
> --- a/libdw/libdwP.h
> +++ b/libdw/libdwP.h
> @@ -1153,8 +1153,7 @@ str_offsets_base_off (Dwarf *dbg, Dwarf_CU *cu)
>if (cu == NULL && dbg != NULL)
> {
>Dwarf_CU *first_cu;
> - if (INTUSE(dwarf_get_units) (dbg, NULL, &first_cu,
> -NULL, NULL, NULL, NULL) == 0)
> + if (dwarf_get_units (dbg, NULL, &first_cu, NULL, NULL, NULL, NULL) ==
> 0)
> cu = first_cu;
> }
Hi mark, sorry for not sharing more yesterday, somehow I locked my account out
on sourceware…. But I can confirm your patch does fix the build.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libelf/32293] New: Build of vl4-utils using elfutils-0.192 libelf (static) fails
https://sourceware.org/bugzilla/show_bug.cgi?id=32293 Bug ID: 32293 Summary: Build of vl4-utils using elfutils-0.192 libelf (static) fails Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libelf Assignee: unassigned at sourceware dot org Reporter: rudi at heitbaum dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- The new eu functions are included in libelf but linkage against libelf fails as below. Believe that this is occurring since https://sourceware.org/git/?p=elfutils.git;a=commit;h=d6443d1a4df6057f9012d105037f52daaca911f1 libeu.a is not installed, so whilst libeu.a has been built, unsure what is suppose to be the correct linkage when statically linking? /build/build.LibreELEC-Generic.x86_64-13.0-devel/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/lib/libelf.a(elf_begin.o):elf_begin.c:function file_read_elf:(.text+0x38b): error: undefined reference to 'eu_search_tree_init' /build/build.LibreELEC-Generic.x86_64-13.0-devel/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/lib/libelf.a(elf_begin.o):elf_begin.c:function file_read_elf:(.text+0x4cb): error: undefined reference to 'eu_search_tree_init' /build/build.LibreELEC-Generic.x86_64-13.0-devel/toolchain/x86_64-libreelec-linux-gnu/sysroot/usr/lib/libelf.a(elf_end.o):elf_end.c:function elf_end:(.text+0xb0): error: undefined reference to 'eu_search_tree_fini' -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/32293] Build of vl4-utils using elfutils-0.192 libelf (static) fails
https://sourceware.org/bugzilla/show_bug.cgi?id=32293
--- Comment #2 from rudi at heitbaum dot com ---
(In reply to Mark Wielaard from comment #1)
> Is there a reason vl4-utils cannot simply be linked shared to libelf?
> In general we aren't really testing static linking.
> Which indeed means it is now broken :{
>
> Maybe something like the following would help?
>
> diff --git a/libelf/Makefile.am b/libelf/Makefile.am
> index 3402863ef174..2d3dbdf22756 100644
> --- a/libelf/Makefile.am
> +++ b/libelf/Makefile.am
> @@ -122,6 +122,9 @@ libelf.so: $(srcdir)/libelf.map $(libelf_so_LIBS)
> $(libelf_so_DEPS)
> @$(textrel_check)
> $(AM_V_at)ln -fs $@ $@.$(VERSION)
>
> +libeu_objects = $(shell $(AR) t ../lib/libeu.a)
> +libelf_a_LIBADD = $(addprefix ../lib/,$(libeu_objects))
> +
> install: install-am libelf.so
> $(mkinstalldirs) $(DESTDIR)$(libdir)
> $(INSTALL_PROGRAM) libelf.so
> $(DESTDIR)$(libdir)/libelf-$(PACKAGE_VERSION).so
>
> I don't have anything to test that with though.
> (You'll need to autoregen -f -v -i)
That indeed does fix the issue.
We generally statically link when shared libraries are not widely used to
reduce disk space in the embedded image. In this case where libelf is linked a
few times against binaries - in the case of keytable to static footprint is
40K, and libelf itself is only 101K is is probably worth reviewing.
--
You are receiving this mail because:
You are on the CC list for the bug.
