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

Mats Wichmann mats at wichmann.us
Fri Apr 22 17:27:07 UTC 2016

On 04/22/2016 11:06 AM, Dallman, John wrote:
> 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

First off, yes... everything you see above is "as expected". The LSB
libraries in /opt/lsb are link-time only libraries; you would expect
that your target system's run-time copies would contain the multiple
versions. It is by this very trick (only one symbol version in LSB
stubs) that building to "a specific LSB version" is made to request the
appropriate symbol versions for that binary.

For browsing the story about symbol versioning and inclusion in LSB
versions, use the LSB Navigator, https://linuxbase.org/navigator

In particular, the memcpy page looks like this:


One of the targets of LSB 5.0 was "uplift glibc to more modern version",
in the memcpy page you will see that there was a symbol version change
at 5.0.

So partly speaking, "downgrade to 4.1" (or earlier) is a good answer -
picking the target LSB version that gets you what you want.

There's another issue to explore: I don't actually expect to see this
problem unless your shared library is explicitly linked against libc, as
otherwise it should not have symbol versions bound into it; but I don't
have time to pursue that just now.

More information about the lsb-discuss mailing list