[lsb-discuss] Using LSB 3.1 or 4.0 shared libraries in an LSB 5.0 link?
mats at wichmann.us
Mon Apr 25 17:55:30 UTC 2016
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 at 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.
More information about the lsb-discuss