Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

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

Successfully merging a pull request may close this issue.

1 participant