[lsb-discuss] Using LSB 3.1 or 4.0 shared libraries in an LSB 5.0 link?

Dallman, John john.dallman at siemens.com
Fri Apr 22 17:06:56 UTC 2016


I've been helping out another team who are using LSB, and I've hit a problem. I think I've got round it, but I'm not sure my diagnosis is correct, nor if this is LSB working as intended.

My employers have a fair-sized organisation, made up of several teams, that produces libraries that are intended as "toolkits", to be used in many different applications, and other toolkits. A toolkit will consist of one of more shared libraries, headers for its APIs, documentation, etc. The list of Linux distributions and versions that the different toolkits and applications support are not identical. For various commercial reasons, some have to support older distributions than others.

So I produce libraries that are built to LSB 3.1 (the next release will move up to 4.0). The other team I've been helping have been working to LSB 5.0, and that seemed to be the problem. When they tried to link one of my LSB 3.1 libraries into their LSB 5.0 application (it's a test harness, not an end-user application) they got this error:

libpskernel.so: undefined reference to `memcpy at GLIBC_2.2.5'

So I went:

$ readelf -sW libpskernel.so | grep GLIBC | grep memcpy
  7696: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy at GLIBC_2.2.5 (5)
 27316: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND memcpy@@GLIBC_2.2.5

So yes, I'm using that symbol. Why can't the linker find it?

$ readelf -sW /opt/lsb/lib64-3.1/libc.so | grep memcpy@
   269: 0000000000009728     6 FUNC    GLOBAL DEFAULT    7 wmemcpy@@GLIBC_2.2.5
   761: 0000000000008e94     6 FUNC    GLOBAL DEFAULT    7 memcpy@@GLIBC_2.2.5  #OK

$ readelf -sW /opt/lsb/lib64-4.0/libc.so | grep memcpy@
   327: 000000000000be7c     6 FUNC    GLOBAL DEFAULT    7 wmemcpy@@GLIBC_2.2.5
   945: 000000000000b46e     6 FUNC    GLOBAL DEFAULT    7 memcpy@@GLIBC_2.2.5  #OK

$ readelf -sW /opt/lsb/lib64-4.1/libc.so | grep memcpy@
   327: 000000000000c014     6 FUNC    GLOBAL DEFAULT    7 wmemcpy@@GLIBC_2.2.5
   950: 000000000000b5fa     6 FUNC    GLOBAL DEFAULT    7 memcpy@@GLIBC_2.2.5  #OK

$ readelf -sW /opt/lsb/lib64-5.0/libc.so | grep memcpy@
   347: 000000000000d6dc     6 FUNC    GLOBAL DEFAULT    7 wmemcpy@@GLIBC_2.2.5
  1025: 000000000000cc4a     6 FUNC    GLOBAL DEFAULT    7 memcpy@@GLIBC_2.14   #Ooops...

Now, it's finding memcpy@@GLIBC_2.2.5, rather than memcpy at GLIBC_2.2.5, and I'm not clear about the difference. Can anyone suggest a source? I'm not doing well at finding details of symbol version semantics online.

I told that team to build to LSB 4.1, and it seems to have got rid of the problem.

Is it meant to be possible to link shared libraries built with older versions of LSB into programs linked with newer versions?

if so, shouldn't /opt/lsb/lib64-5.0/libc.so be providing memcpy@@GLIBC_2.2.5? I have lsb-build-base-5.0.0-2.x86_64, which is from lsb-sdk-5.0.0-3.x86_64.tar.gz, which still seems to be the current release.

thanks,

--
John Dallman

-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20160422/449356cc/attachment.html>


More information about the lsb-discuss mailing list