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@GLIBC_2.2.5' > > So I went: > > $ readelf -sW libpskernel.so | grep GLIBC | grep memcpy > 7696: 0000000000000000 0 FUNC GLOBAL DEFAULT UND memcpy@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@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: http://linuxbase.org/navigator/browse/int_single.php?cmd=list-by-name&Ilibrary=libc&Iname=memcpy 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. _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
