[cmake-developers] Apple tests for target_link_libraries failing
Stephen Kelly
steveire at gmail.com
Thu Oct 13 18:43:01 EDT 2011
Stephen Kelly wrote:
>
> Ok, knowing why it fails on APPLE is good enough for me for now.
>
> The tests can be enabled on APPLE again later, I've flipped the if
> condition so we can see why it fails on some non-APPLE platforms too.
>
I was given access to a freebsd box to see why the build succeeds there.
The link line looks like this:
~/test19-build]$ vi CMakeFiles/exec.dir/link.txt
/usr/bin/c++ -Wl,-no-as-needed CMakeFiles/exec.dir/main.cpp.o -o exec
lib/liblibC.so -Wl,-rpath,/home/steve/test19-build/lib -Wl,-rp
ath-link,/home/steve/test19-build/lib
and then ldd reports that it is also linked against liblibB.so.
~/test19-build]$ ldd exec
exec:
liblibC.so => /home/steve/test19-build/lib/liblibC.so (0x800849000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x800a4a000)
libm.so.5 => /lib/libm.so.5 (0x800d55000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800f76000)
libc.so.7 => /lib/libc.so.7 (0x801183000)
liblibB.so => /home/steve/test19-build/lib/liblibB.so (0x8014cb000)
liblibA.so => /home/steve/test19-build/lib/liblibA.so (0x8016cc000)
Nope, you got that wrong. What that means is that liblibB.so will get loaded
to satisfy some dynamic library dependencies when exec is called. It does not
mean that exec got linked against liblibB, but that exec or any of it's
dependencies was linked against liblibB. So you will likely see the very same
result on any exec that was successfully linked. What you are looking for is
objdump or readelf, they will tell you what is actually in exec and not in
it's dependencies.
Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20111014/5959d096/attachment.sig>
More information about the cmake-developers
mailing list