FreeBSD build problem

[Alexander Neundorf]

On Monday 07 July 2008, Brad King wrote:
> David Faure wrote:
> > The -L parameters are definitely generated, by cmake.
> > The question is how. And the answer is complex AFAIK, and depends on the
> > cmake version.
>
> In CMake 2.4 the set of -L paths come from arguments to the
> link_directories() command and the locations of libraries given to
> target_link_libraries() by full path.  In CMake 2.6 the latter case is
> usually handled just by passing the full path to the library file
> directly to the linker with no searching, but there are still some cases
> where it behaves similarly to 2.4.
>
> The input to the ordering algorithm is the original list of
> user-specified library search paths (given to link_directories) plus
> some set of library file full paths.  The output is an ordered linker
> search path.  We try to preserve the original order of user-specified
> directories, but the main rule is that the order is such that the
> libraries whose full paths are known will be found first if the linker
> searches for them with a -lfoo option.  This guarantees that when a
> library is specified by full path that the copy of the library is
> favored over any other copy of the library at another place in the
> linker search path.
>
> CMake actually inspects all the linker search path locations to look for
> possibly conflicting files and builds a constraint graph.  A topological
> sort on the resulting constraint graph produces the order.  The order
> among an unconstrained group of paths is that in the original

Yes.
If you use this:

target_link_libraries(kfind  ${KDE4_KDE3SUPPORT_LIBS} )

the kde3support library and all libs it depends on will be linked to kfind.
The kde3support library itself is found using a FIND_LIBRARY() call and so 
will be given to cmake with the full path, 
e.g. /opt/kde4/lib/libkde3support.so.
Additionally all the libs from kde3support_LIB_DEPENDS will also be linked, 
which looks (on my system) like this:
 
SET("kde3support_LIB_DEPENDS" "/opt/qt-copy/lib/libQtCore.so;-lpthread;kdecore;kdeui;kio;kparts;/opt/qt-copy/lib/libQtCore.so;
-lpthread;kdecore;kpty;/opt/qt-copy/lib/libQtXml.so;/opt/qt-copy/lib/libQt3Support.so;/opt/qt-copy/lib/libQtCore.so;-lpthread;kdecore;
kdeui;kio;kfile;")

Here kdecore, kdeui etc. are given without full path. This is because when 
building kdelibs they are only the target names, not file names of the 
not-yet-installed libraries.
So when cmake checks the order of the library dirs, it probably doesn't see a 
problem: libkde3support.so is unique (only in the KDE4 lib dir), kdeui, 
kdecore etc. exist in both dirs, but nobody told cmake that we would like to 
have the one in the KDE4 dir, so it doesn't complain.

Now if you add ${KDE4_KDEUI_LIBS}, kdeui will be added with the full path (as 
above with kde3support), so now cmake will detect the problem (libkdeui.so 
both in the KDE3 and KDE4 lib dirs) and order them so that you get 
libkdeui.so from the KDE4 lib dir.

Short version: this is an ugly situation

I think we can fix this for KDE 4.2 with cmake 2.6.
What do we do in the meantime ?
We could add ${KDE4_KDECORE_LIBRARY} (which comes with the full path and 
features the same name as the one from KDE3) as a direct dependency for all 
libs from kdelibs (in FindKDE4Internal.cmake), so this conflict would be 
always detected.
Does that make sense ?

Alex