On 04/25/2016 07:39 AM, Mats Wichmann wrote: > 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.
For those not following bugzilla, I filed this as an issue (bug 4161) and pushed a few quick adjustments which now let me produce a simple test library that does not show resolution against the standard libraries. _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
