[cmake-developers] Apple tests for target_link_libraries failing

[Stephen Kelly]

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)


I can't explain why. I also tried with 

export LDFLAGS=-Wl,-no-as-needed

with the same result.

For the moment I think I'll give up on testing the actual result of the 
build, but I'll just compare the result with the 'control point' of building 
with all targets with their LINK_INTERFACE_LIBRARIES set to empty. 

That will be a good enough unit test for the CMAKE_LINK_INTERFACE_LIBRARIES 
and makes fixing all of the issues with it not my responsibility :).

It also means that I don't become an expert in linker options :).

Should be done tomorrow.

Thanks,

Steve.