On 04/25/2016 07:08 AM, Dallman, John wrote: > I wrote: >> Mats wrote: >>> 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. >> I'll experiment with that. > > Well, I tried taking -lc -lm out of my lsbcc command, but it made no > difference: I still get the reference to memcpy@GLIBC_2.2.5. > > The actual link line for my shared library, as displayed by using the > --lsb-verbose option to lsbcc, is: > > cc -o ./libpskernel.so -I /opt/lsb/include -m64 -fPIC -shared ((lots of > object files)) /path/to/pskernel_archive.a -D__LSB_VERSION__=40 > -nodefaultlibs -L /opt/lsb/lib64-4.0 -Wl,-Bsymbolic > -Wl,-soname=libpskernel.so -Wl,-z,relro,-z,now,-z,noexecstack -lpthread > -lpthread -lpthread_nonshared -fno-stack-protector -L > /usr/lib64/gcc/x86_64-suse-linux/4.3 -L/lib64 -L/usr/lib64 > -Wl,--hash-style=sysv -lgcc -lm -lc -lc_nonshared -lgcc > > So lsbcc is putting in the -lc -lc_nonshared, even if I don't do so myself. > > Any ideas?
you may have found a bug. I see the same effect... building a shared library directly with ld, instead of through lsbcc, does not "bind" these symbol versions. _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
