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 ----------------- 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.
_______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
