Reputation: 10371
I've got a binary "CeeloPartyServer" that needs to find libFoundation.so at runtime, on a FreeBSD machine. They're both in the same directory. I compile (on another platform, using a cross compiler) CeeloPartyServer using linker flag -rpath=$ORIGIN
.
> readelf -d CeeloPartyServer |grep -i rpath
0x0000000f (RPATH) Library rpath: [$ORIGIN]
> ls
CeeloPartyServer Contents Foundation.framework libFoundation.so
> ./CeeloPartyServer
/libexec/ld-elf.so.1: Shared object "libFoundation.so" not found, required by "CeeloPartyServer"
Why isn't it finding the library when I try to run it?
My exact linker line is: -lm -lmysql -rpath=$ORIGIN
.
I am pretty sure I don't have to escape $ or anything like that since my readelf analysis does in fact show that library rpath is set to $ORIGIN. What am I missing?
Upvotes: 27
Views: 24364
Reputation: 566
using ldd CeeloPartyServer
to check the dependency .so is starting with ./
or not. (e.g. libFoundation.so
and ./libFoundation.so
)
For common situation it should be libFoundation.so
and without the prefix ./
if ./
prefix is necessary for some uncommon case, make sure the CWD is the same folder with libFoundation.so
, and the $ORIGIN
would be invalid.
=======
For example:
g++ --shared -Wl,--rpath="\$ORIGIN" ./libFoundation.so -o lib2.so
would got a library lib2.so
with ./libFoundation.so
g++ --shared -Wl,--rpath="\$ORIGIN" libFoundation.so -o lib2.so
would got libFoundation.so
instead.
Upvotes: 0
Reputation: 101
\$\ORIGIN if you are using chrpath and \$\$ORIGIN if you are providing directly in LDFLAGS
Upvotes: 3
Reputation: 12727
I'm assuming you are using gcc and binutils.
If you do
readelf -d CeeloPartyServer | grep ORIGIN
You should get back the RPATH line you found above, but you should also see some entries about flags. The following is from a library that I built.
0x000000000000000f (RPATH) Library rpath: [$ORIGIN/../lib]
0x000000000000001e (FLAGS) ORIGIN
0x000000006ffffffb (FLAGS_1) Flags: ORIGIN
If you aren't seeing some sort of FLAGS entries, you probably haven't told the linker to mark the object as requiring origin processing. With binutils ld, you do this by passing the -z origin
flag.
I'm guessing you are using gcc to drive the link though, so in that case you will need to pass flag through the compiler by adding -Wl,-z,origin
to your gcc link line.
Upvotes: 47
Reputation: 32392
Depending on how many layers this flag passes through before the linker sees it, you may need to use $$ORIGIN
or even \$$ORIGIN
. You will know that you have it right when readelf
shows an RPATH header that looks like $ORIGIN/../lib
or similar. The extra $ and the backslash are just to prevent the $ from being processed by other tools in the chain.
Upvotes: 17