Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Couldn't find DT_RPATH tag #174

Closed
JonathonReinhart opened this issue Apr 20, 2021 · 3 comments · Fixed by #175
Closed

Couldn't find DT_RPATH tag #174

JonathonReinhart opened this issue Apr 20, 2021 · 3 comments · Fixed by #175
Labels

Comments

@JonathonReinhart
Copy link
Owner

When running a staticx-bundled program, we sometimes see this error:

myprog: Couldn't find DT_RPATH tag
@JonathonReinhart
Copy link
Owner Author

JonathonReinhart commented Apr 20, 2021

The problem is with patchelf (again).

Even though we're using --force-rpath:

DEBUG:root:Running ['patchelf', '--set-interpreter', 'iiiii...', '--set-rpath', 'rrrrr...', '--force-rpath', '/tmp/staticx-prog-_u662iwb']

We still see a RUNPATH tag in the output:

 0x000000000000001d (RUNPATH)            Library runpath: [rrrrr...]

This was supposedly fixed in NixOS/patchelf#137 (NixOS/patchelf@67091ca), which first appeared in 0.11.

Debian buster provides patchelf 0.9+52.20180509-1 (which identifies as patchelf 0.10) which is too old.


Similar to 82b9564, the workaround seems to be to run once with --remove-rpath, and then as usual.

This is also the workaround used here: pypa/auditwheel#173

It's also worth noting that pypa guys considered alternatives to patchelf: pypa/auditwheel#174

@JonathonReinhart
Copy link
Owner Author

JonathonReinhart commented Apr 20, 2021

How am I just now finding this bug? I've been running Buster for a long time.

I thought the difference was SCons, but this happens even with v3.0.1 (default).

I guess it's probably because Travis is still using xenial (16.04 LTS) which probably doesn't use RUNPATH by default.

I really need to move away from Travis (#124).

Update: Confirmed: ld 2.26.1 (in ubuntu:xenial) produces an app with RPATH (0xf) as opposed to RUNPATH (0x1d) in ld 2.31.1 (Buster).

@JonathonReinhart
Copy link
Owner Author

JonathonReinhart commented Apr 20, 2021

I tried running this myself with the ubuntu:xenial docker image, and I hit yet another weird issue:

# cd test/rpath-origin
# scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build
gcc -o build/app.o -c -Wall -Werror app.c
gcc -o build/libfoo.os -c -Wall -Werror -fPIC libfoo.c
gcc -o build/libbar.os -c -Wall -Werror -fPIC libbar.c
gcc -o build/libbar.so -z origin -shared -Wl,-rpath=\$ORIGIN build/libbar.os -Ldist/lib
Install file: "build/libbar.so" as "dist/lib/libbar.so"
gcc -o build/libfoo.so -z origin -shared -Wl,-rpath=\$ORIGIN build/libfoo.os -Ldist/lib -lbar
Install file: "build/libfoo.so" as "dist/lib/libfoo.so"
gcc -o build/app -z origin -Wl,-rpath=\$ORIGIN/../lib build/app.o -Ldist/lib -lfoo
/usr/bin/ld: warning: libbar.so, needed by dist/lib/libfoo.so, not found (try using -rpath or -rpath-link)
dist/lib/libfoo.so: undefined reference to `bar_nop'
collect2: error: ld returned 1 exit status
scons: *** [build/app] Error 1
scons: building terminated because of errors.

I have no idea why this isn't happening in Travis. But I added -rpath-link and fixed it.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant