RE: libosmoabis depends on libosmovty

Hi Holger, Yes, here’s the link line for libosmoabis, showing the link of vty and dependent libs: /bin/sh ../libtool --tag=CC --mode=link arm-x-linux-gnueabi-gcc -Wall -I/.build/usr/local/include/ -I/.build/usr/local/include/ -I/.build/usr/local/include/ -D_REENTRANT -DORTP_INET6 -I /.build/usr/local/include -g -O2 -version-info 0:0:0 -o libosmotrau.la -rpath /usr/local/lib libosmotrau_la-osmo_ortp.lo -L/.build/usr/local/lib -losmocore -L/.build/usr/local/lib -losmogsm -L/.build/usr/local/lib -losmovty -L/.build/usr/local/lib -lortp -lpthread -lrt Sure is: $ arm-x-linux-gnueabi-objdump -x libosmoabis.so | grep NEEDED NEEDED libosmocore.so.6 NEEDED libosmogsm.so.5 NEEDED libosmovty.so.1 NEEDED libgcc_s.so.1 NEEDED libc.so.6 This is cross-compiling for arm, gcc from Sourcery CodeBench Lite 2012.09-104, 4.7.2. I cross-compile and install to a stage using DESTDIR at the install step. This means that at link time the rpath, while correct for the final system, isn't valid (which is pretty much what the linker is hinting at in the warning). Also from 'man ld': "The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link" So rpath makes it work if building and installing either natively or to a mocked environment, but we become stuck if staging in a different directory. Passing the library itself uses different search rules, and so that works. I guess the other options are to hack with LDFLAGS and LIBS in the build, or set LD_RUN_PATH in the environment. I'll keep the patch locally for now I think though... Kind Regards, Mike