Version 'Glibc_2.32' Not Found Error When Running Petalinux-Build

version `GLIBC_2.32' not found error when running petalinux-build

/home/MY_USER/.../sysroots-uninative/x86_64-linux/lib/libc.so.6: version 'GLIBC_2.32' not found (required by /lib64/libgomp.so.1)

You are mixing system libgomp.so.1 with sysroot libc.so.6 -- this will never end well. You probably need to build libgomp.so.1 in the sysroot as well.

And if I run /lib/libc.so.6, I get:

That is irrelevant -- you link isn't failing with that library, but with the sysroot one.

If you run /home/MY_USER/path/Project/xilinx-zc702-2018.2/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6, you'll see that it is in fact too old (older than 2.32).

configure: error: missing __attribute__ ((constructor)) support?

Since you enabled code coverage support by adding these CFLAGS -fprofile-arcs -ftest-coverage - these CFLAGS must have been propagated to compilation of conftest binary that is built by autoconf. This binary is built to test if one specific feature (as it says "whether to use .ctors/.dtors header and trailer") is supported or not (actually, there are several similar builds occur in configuration process to test for specific features). I cannot prove that, because detailed error prints should be in specific log file that you haven't shared:

| NOTE: The following config.log files may provide further information.
| NOTE: /scratch/work/day8/poky/build/tmp/work/i586-poky-linux/glibc/2.28-r0/build-i586-poky-linux/config.log

But, I bet, it should contain something like:

conftest.c:(.text+0xae): undefined reference to `__gcov_init'
...
collect2: ld returned 1 exit status

This is because the code is instrumented with some function calls and linker can't find its implementations (even in these conftest binaries where they are absolutely have no sense).

It is possible to skip this particular configuration test by specifying corresponding configuration option - libc_cv_ctors_header (in this case, name is taken from glib's configure.ac) - adding EXTRA_OECONF to local.conf (e.g. EXTRA_OECONF = "libc_cv_ctors_header=yes"), but those flags, actually affect all such tests, and we shouldn't want to guess yes/no values and so on.

Thus, it'd be better to make linker be aware of coverage support - i.e. provide the same flags for TARGET_LDFLAGS:

TARGET_LDFLAGS += "-fprofile-arcs -ftest-coverage"

(pam_ldap.so) /lib/libc.so.6: version `GLIBC_2.28' not found

Can anyone help me understand the source of the problem?

You linked libldap-2.4.so.2 against GLIBC-2.28 (or later).

But at runtime, the version of GLIBC is 2.27 (or earlier).

GLIBC supports backward compatibility (binaries built against earlier version of GLIBC continue to run on systems with newer GLIBC versions).

But it doesn't support "build on newer, run on older" compatibility.

Error undefined hidden symbol `__dso_handle' can not be used when making a shared object

I tried with the definition in dso_handle.h as below:

void *__dso_handle __attribute__((weak)) = NULL;

But, it didn't work in my case.

The error looked like comming from gcc compatibility.

And my solution is

I upgraded the build host's gcc version (>= 7.5.0) then cleanup and rebuild glibc. And the result is okay.

Multiple glibc libraries on a single host

It is very possible to have multiple versions of glibc on the same system (we do that every day).

However, you need to know that glibc consists of many pieces (200+ shared libraries) which all must match. One of the pieces is ld-linux.so.2, and it must match libc.so.6, or you'll see the errors you are seeing.

The absolute path to ld-linux.so.2 is hard-coded into the executable at link time, and can not be easily changed after the link is done (Update: can be done with patchelf; see this answer below).

To build an executable that will work with the new glibc, do this:

g++ main.o -o myapp ... \
   -Wl,--rpath=/path/to/newglibc \
   -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2

The -rpath linker option will make the runtime loader search for libraries in /path/to/newglibc (so you wouldn't have to set LD_LIBRARY_PATH before running it), and the -dynamic-linker option will "bake" path to correct ld-linux.so.2 into the application.

If you can't relink the myapp application (e.g. because it is a third-party binary), not all is lost, but it gets trickier. One solution is to set a proper chroot environment for it. Another possibility is to use rtldi and a binary editor. Update: or you can use patchelf.

---

Related Topics