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 ? Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
