libosmoabis depends on libosmovty

Hi Folks,

When I build OpenBsc, I find a number of cases where libosmovty isn't in the link, but is needed by libosmoabis (basically anywhere libosmoabis is linked, but vty isn't) e.g.

/bin/ld: warning: libosmovty.so.1, needed by /.build/usr/local/lib/libosmoabis.so, not found (try using -rpath or -rpath-link)
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_node'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element_ve'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out_rate_ctr_group'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_out'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `install_element'
/.build/usr/local/lib/libosmoabis.so: undefined reference to `vty_install_default'

I'm not sure why/how I'm seeing this and others apparently aren't, but it looks legitimate.  I've verified the configure script has [correctly] derived build configfrom the staged pkgconfig:

LIBOSMOABIS_CFLAGS='-I/.build/usr/local/include/  '
LIBOSMOABIS_LIBS='-L/.build/usr/local/lib -losmoabis  '

So I wonder if libosmoabis.pc.in should be updated to include vty, a bit like libosmogb.pc.in i.e.

Signed-off-by: Michael McTernan <Michael.McTernan@wavemobile.com>
Otherwise every user of libosmoabis has to remember to link with -losmovty as well.

Kind Regards,

Mike
PS: I've stripped the very long full build paths from output - I don't really build in /.build!

> On 02 Jun 2015, at 14:50, Mike McTernan (wavemobile) <mike.mcternan@wavemobile.com> wrote:
> 
> Hi Folks,

Hi!

 
> When I build OpenBsc, I find a number of cases where libosmovty isn’t in the link, but is needed by libosmoabis (basically anywhere libosmoabis is linked, but vty isn’t) e.g.
>  
> /bin/ld: warning: libosmovty.so.1, needed by /.build/usr/local/lib/libosmoabis.so, not found (try using -rpath or -rpath-link)
> /.build/usr/local/lib/libosmoabis.so: undefined reference to `install_node’


> -Libs: -L${libdir} -losmoabis
> +Libs: -L${libdir} -losmoabis -losmovty


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. I assume that there
is a NEEDED entry in the elf header of libosmo-abis.

Which system do you compile it on? I think the above is kind of a work-around for another
issue in the system.

holger

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

> On 02 Jun 2015, at 16:44, Mike McTernan (wavemobile) <mike.mcternan@wavemobile.com> wrote:
> 
> Hi Holger,

Hi!



>> 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’:

yes, you then need to have -rpath-link in your LDFLAGS to help the linker find the
temporary libosmovty.so


holger