I develop software for an embedded device using the PowerPC architecture. Recently we got a new firmware upgrade and the manufacturer has provided a toolchain which is incapable of building runnable binaries.

Except for a few exceptions, where I've completely statically compiled the binary, the OS gives me following error:

isobuslog.bin: /lib/ld.so.1: version `GLIBC_2.22' not found (required by isobuslog.bin)

I've been up and down a multitude of mailing lists and threads all day, looking for a solution to this. I finally read a post where following command was entered: powerpc-linux-gnu-readelf -Ws app/bin/isobuslog.bin | grep GLIBC_2.22

The output is as follows:

142: 00000000     0 FUNC    GLOBAL DEFAULT  UND __tls_get_addr_opt@GLIBC_2.22 (14)

Looking further in to the matter, it seems this is a thread-local storage optimisation routine which became available w/ GLIBC v2.22. Both the SDK I was provided and the SDK I installed myself both have GLIBC version higher than 2.22 and at least G 6.3 (6.3 provided by OEM, 9.2.1 installed locally on my machine) - so there's no way around this, unless I use the previous VM provided, which is based on an old Debian using GCC 4.6 - this is not an option, as we require C 11 and higher, without the use of Boost.

I've tried searching around some more, and have found these two linker flags which don't seem to work, causing the linker to exit with an error code, saying it couldn't recognise the flags provided.

• --no-tls-optimize
• --no-tls-get-addr-optimize

Is there a way to disable __tls_get_addr_opt so that my applications will build, or is there a way around this issue (except going back to ancient times)?

CodePudding user response：

I've finally figured it out.

The trick is to tell G to pass the parameters to the linker. This was achieved by adding the aforementioned switches to the comma-separated list like so:

-Wl,-rpath-link,${DEPS_DIR}/powerpc-linux-gnu/lib,--no-tls-optimize,--no-tls-get-addr-optimize