Re: FreeBSD build problem
On Monday 07 July 2008 11:51:21 am Alexander Neundorf wrote:
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 ?
I made a patch that applies this, and added it to the FreeBSd port. So far it
is working. I'll do some more builds tomorrow.
Thank you,
--
David Johnson
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
On Sunday 06 July 2008 07:45:46 pm Thiago Macieira wrote:
David Johnson wrote:
target_link_libraries(kfind ${KDE4_KDE3SUPPORT_LIBS} )
This results in the the following library
locations: -L/usr/local/lib/qt4 -L/usr/local/lib -L/usr/local/kde4/lib
However, changing that line to add a dependency:
target_link_libraries(kfind ${KDE4_KDEUI_LIBS} ${KDE4_KDE3SUPPORT_LIBS}
)
Those libraries link directly to kdeui anyways, so the change is harmless.
It can easily be done.
But can anyone tell me how those library lists get generated? It seems very
arbitrary and random. I would be much more comfortable writing these patches
if I knew what was happening under the surface.
--
David Johnson
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
David Johnson wrote:
On Sunday 06 July 2008 07:45:46 pm Thiago Macieira wrote:
David Johnson wrote:
target_link_libraries(kfind ${KDE4_KDE3SUPPORT_LIBS} )
This results in the the following library
locations: -L/usr/local/lib/qt4 -L/usr/local/lib
-L/usr/local/kde4/lib
However, changing that line to add a dependency:
target_link_libraries(kfind ${KDE4_KDEUI_LIBS}
${KDE4_KDE3SUPPORT_LIBS} )
Those libraries link directly to kdeui anyways, so the change is
harmless. It can easily be done.
But can anyone tell me how those library lists get generated? It seems
very arbitrary and random. I would be much more comfortable writing
these patches if I knew what was happening under the surface.
It wasn't generated. It was written by hand like above.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
On Monday 07 July 2008, Thiago Macieira wrote:
David Johnson wrote:
On Sunday 06 July 2008 07:45:46 pm Thiago Macieira wrote:
David Johnson wrote:
target_link_libraries(kfind ${KDE4_KDE3SUPPORT_LIBS} )
This results in the the following library
locations: -L/usr/local/lib/qt4 -L/usr/local/lib
-L/usr/local/kde4/lib
However, changing that line to add a dependency:
target_link_libraries(kfind ${KDE4_KDEUI_LIBS}
${KDE4_KDE3SUPPORT_LIBS} )
Those libraries link directly to kdeui anyways, so the change is
harmless. It can easily be done.
But can anyone tell me how those library lists get generated? It seems
very arbitrary and random. I would be much more comfortable writing
these patches if I knew what was happening under the surface.
It wasn't generated. It was written by hand like above.
Thiago, I think you're not understanding David Johnson's question :)
The -L parameters are definitely generated, by cmake.
The question is how. And the answer is complex AFAIK, and depends on the cmake
version.
--
David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
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 user-specified order. This is done much more formally in CMake 2.6 than in 2.4. -Brad ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
On Monday 07 July 2008 05:21:48 am Thiago Macieira wrote: But can anyone tell me how those library lists get generated? It seems very arbitrary and random. I would be much more comfortable writing these patches if I knew what was happening under the surface. It wasn't generated. It was written by hand like above. I must learn to write English better. What I meant was, how does *cmake* generate the list of libraries sent to the linker, and what determines their order? I've looked at FindKDE4Internal.cmake, but I don't fully understand it. -- David Johnson ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
On Monday 07 July 2008 08:00:10 am David Faure wrote: Thiago, I think you're not understanding David Johnson's question :) The -L parameters are definitely generated, by cmake. The question is how. And the answer is complex AFAIK, and depends on the cmake version. Thanks. And thanks to Brad King for his detailed explanation. The upshot is that I can't guarantee the order of search paths, as they may change through a variety of causes. I guess I'll have to bite the bullet and give KDE3 its own hierarchy. As painful as that is, it will upset far fewer users than telling them they can't have KDE3 and KDE4 on the same system. -- David Johnson ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: FreeBSD build problem
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
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
FreeBSD build problem
I am having some problems building kde 4.0.83. A few executables are linking
with the KDE3 libraries. So far these are kdialog, kfind and kmenuedit. I
have only built up to kdebase/kdebase-workspace so far.
Currently in FreeBSD, KDE3 is installed to /usr/local. We have given Qt4 and
KDE4 their own private directories to live in, but in the meantime *every*
user has KDE3 in /usr/local.
The problem occurs because in these three apps, -L/usr/local/lib is being
listed before -L/usr/local/kde4/lib. That causes the app to link to KDE3 libs
instead of KDE4. This isn't happening in other apps. Looking closer, the
CMakeLists.txt for kfind has the line:
target_link_libraries(kfind ${KDE4_KDE3SUPPORT_LIBS} )
This results in the the following library
locations: -L/usr/local/lib/qt4 -L/usr/local/lib -L/usr/local/kde4/lib
However, changing that line to add a dependency:
target_link_libraries(kfind ${KDE4_KDEUI_LIBS} ${KDE4_KDE3SUPPORT_LIBS} )
now results in a better library order:
-L/usr/local/lib/qt4 -L/usr/local/kde4/lib -L/usr/local/lib
Obviously, I shouldn't have to add superflous dependencies. But I can't figure
out how cmake generates the order of libraries. I have no idea how to fix
this. I also notice that some dependencies are listed with their full path,
but others not. If all dependencies could be listed by path it would solve
this. But I have no idea how to do it.
Any help would be appreciated.
--
David Johnson
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
