Howto fix KDE4 Buildsystem with CMake CVS
brad.king at kitware.com
Wed Feb 20 05:10:19 CET 2008
Alexander Neundorf wrote:
> On Sunday 17 February 2008, Brad King wrote:
>> Alexander Neundorf wrote:
>>> There is still the problem with OUTPUT_NAME which is a real bug.
>> We can fix that in 2.6, but without another patch release to 2.4 that
>> gets put in all the major distros you won't be able to depend on the fix
>> anyway. You should probably use OUTPUT_NAME only on an executable
>> target to give it the same name as a library. Then the library can
>> export with the correct name.
>>>> How was this all working with 2.4? Do the effects of
>>>> CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that
>>> Actually I'd like to use the new style, since this will avoid the
>>> problems it is supposed to avoid :-)
>> Whether CMAKE_LINK_OLD_PATHS is defined or not the full paths to known
>> libraries are still given to the linker. The option only enables
>> passing of their locations in -L paths for no reason but compatibility
>> with projects that don't call LINK_DIRECTORIES properly.
> I just tried that and still got:
> Linking C executable hello
> /opt/cmake-HEAD/bin/cmake -E cmake_link_script
> CMakeFiles/hello.dir/link.txt --verbose=1
> /usr/bin/gcc -fPIC "CMakeFiles/hello.dir/main.o" -o hello -rdynamic
> libfoo.so /opt/test2/lib/libkdefx.so -Wl,-rpath,/home/alex/src/tests/rpathtest/b2:/opt/test2/lib
> Shouldn't there be -L/opt/test2/lib/ included ?
> I have set both variables:
> set(CMAKE_LINK_OLD_PATHS TRUE)
> set(CMAKE_BACKWARDS_COMPATIBILITY 2.4)
> Am I missing something ?
The -L options are added only if there are some -lfoo options.
Otherwise they are useless anyway.
More information about the Kde-buildsystem