Hello all,

I'll apologize up front if my issue is not appropriate for this list or
is answered elsewhere, but I thought I'd come straight to the source...

I've noticed that setting the RPATH of a binary will help find libraries
that the binary has been linked against, but the RPATH of the binary is
ignored when a library itself is linked to another library. Is this
expected behavior?

Below is a demonstration of the behavior:

hornerj@biostatbsd ~/testrtl
$ cat main.c

void print_hello_lib1(void);

int main(int argc, char **argv){
printf("hello from main\n");
hornerj@biostatbsd ~/testrtl
$ cat lib1.c

void print_hello_lib2(void);

void print_hello_lib1(void){
printf("hello from lib1\n");
hornerj@biostatbsd ~/testrtl
$ cat lib2.c

void print_hello_lib2(void){
printf("hello from lib2\n");
hornerj@biostatbsd ~/testrtl
$ make clean
rm *.o *.so runmain
hornerj@biostatbsd ~/testrtl
$ make
gcc -c main.c
gcc -fPIC -c lib2.c
gcc -shared -Wl,-soname,lib2.so -o lib2.so lib2.o
gcc -fPIC -c lib1.c
gcc -shared -Wl,-soname,lib1.so -o lib1.so lib1.o lib2.so
gcc -L. -l1 -Wl,-rpath,`pwd` -o runmain main.o
hornerj@biostatbsd ~/testrtl
$ ./runmain
/libexec/ld-elf.so.1: Shared object "lib2.so" not found, required by
$ gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518

So, I realize I can overcome this by setting the RPATH of lib1.so, but I
just wanted to make sure that this is expected (since on another
platform that's not necessary).

Thanks in advance,

freebsd-hackers@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"