Created attachment 738991 [details]
tar ball of main.cpp and output
After installing Tumbleweed and updating as of yesterday (30-08-2017) I'm
seeing the ld search paths fail to pick up libraries that were picked up
before.
I'd expect to see search paths containing the current architecture (x86_64), to
assist in finding architecture specific libraries for different CPU features.
I'm finding the path populated with "haswell" instead, causing issues in our
case with trying to run Feral Interactive games on steam.
To reproduce:
Compile the attached main.cpp with the following command:
$ g++ main.cpp -Wl,--disable-new-dtags,-rpath,\$ORIGIN/lib/
And then check the library search paths with this command:
$ LD_DEBUG=libs ldd ./a.out
See attached output from local machine. Note this output:
search
path=/home/mdiluzio/lib/tls/haswell:/home/mdiluzio/lib/tls:/home/mdiluzio/lib/haswell:/home/mdiluzio/lib
(RPATH from file /home/mdiluzio/a.out)
Previously, and on other available distributions, we saw search paths
containing the architecture. Without these paths programs that rely on this
behaviour will fail to find the required libraries that are contained in an
"x86_64" sub-directory of the specified RPATH.
We think these paths should be coming from _gl_important_hwcaps in glibc's
elf/dl-hwcaps.c, but haven't yet traced the root cause of change in behaviour.
We're unsure if the behaviour of the ld search paths is not stable enough to be
relied on in this way, or if this is in fact a configuration bug, so any help
would be appreciated.
uname -a: Linux localhost 4.12.8-1-default #1 SMP PREEMPT Thu Aug 17 05:30:12
UTC 2017 (4d7933a) x86_64 x86_64 x86_64 GNU/Linux
Please note, a similar issue has been seen recently by one user on Arch as
reported here:
https://github.com/FeralInteractive/ferallinuxscripts/issues/3
That could be a hint that this is a wider reaching ld, glibc or kernel related
issue, but since it manifests differently on Tumbleweed, and that's the
reproduction case I have, I'm reporting it here.