libosmoabis depends on libosmovty

[Mike McTernan (wavemobile)]

Hi Holger,
 
> When I grew up the rule was link to the libraries whose symbols you are
> using. In this case libosmo-abis does use libosmovty symbols and it does link
> to it.

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   

> I assume that there is a NEEDED entry in the elf header of libosmo-abis.

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
 
> Which system do you compile it on?

This is cross-compiling for arm, gcc from Sourcery CodeBench Lite 2012.09-104, 4.7.2.

> I think the above is kind of a work-around for another issue in the system.

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