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