On Wednesday 17 June 2009, Andreas Pakulat wrote:
> Resending as Alex lost his copy and I'd like to get his answer easily
> onto this list, hope the other readers don't mind.
>
> On 07.06.09 21:50:06, Andreas Hartmetz wrote:
> > On Sunday 07 June 2009 01:39:56 Andreas Pakulat wrote:
> > > On 06.06.09 21:05:34, Andreas Hartmetz wrote:
> > > > SVN commit 978363 by ahartmetz:
> > > >
> > > > link with gold
> > > >
> > > >  M  +6 -4      git/tests/CMakeLists.txt
> > > >  M  +2 -0      mercurial/tests/CMakeLists.txt
> > > >  M  +1 -1      snippet/CMakeLists.txt
> > > >
> > > >
> > > > --- trunk/KDE/kdevplatform/plugins/git/tests/CMakeLists.txt
> > > > #978362:978363 @@ -20,13 +20,15 @@
> > > >      set( EXECUTABLE_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR} )
> > > >  	set(gitInitTest_SRCS initTest.cpp ../gitplugin.cpp)
> > > >      kde4_add_unit_test(kdevgit-test ${gitInitTest_SRCS})
> > > > -	target_link_libraries(kdevgit-test
> > > > -		${QT_QTTEST_LIBRARY}
> > > > -		${KDE4_KDECORE_LIBS}
> > > > +    target_link_libraries(kdevgit-test
> > > > +        ${QT_QTTEST_LIBRARY}
> > > > +        ${KDE4_KDECORE_LIBS}
> > > > +        kdevplatformshell
> > > > +        kdevplatforminterfaces
> > > >          kdevplatformutil
> > > >          kdevplatformvcs
> > > >          kdevplatformtestshell
> > >
> > > This shouldn't be needed kdevplatformtestshell sets kdevplatformshell
> > > as link-interface library, which means the linker is supposed to
> > > automatically link the library in. This suggests that either your
> > > linker is broken, or CMake needs special support for the gold linker.
> > > Please revert this and the similar commit you've done to kdevelop (the
> > > same applies to the other 2 files this commit changes).
> >
> > The link interface libraries should, for all I know, be added to the g++
> > / ld command-line by cmake. KOffice for example builds just fine after
> > all its libraries have gotten a comprehensive link interface. I had a
> > discussion about this with Thomas Zander and it turned out that this was
> > how it was supposed to work but it broke and people using ld didn't
> > notice. Thomas fixed just a few lines in some CMakeLists.txt and all the
> > linker errors were gone. I suspect that the link interface setup here
> > somehow doesn't work.
>
> Moving over to kde-buildsystem to get some more input.
>
> Maybe I misunderstood how the link-interface-libs stuff is supposed to
> work. So far I though that if kdevplatformtestshell library declares
> kdevplatformshell as one of its link-interface libraries, then cmake will
> automatically add the kdevplatformshell library to any other target that
> links against kdevplatformtestshell. In the same way kdevplatformshell has
> kdevplatforminterfaces as its link-interface-lib, hence a target linking to
> kdevplatformshell should get kdevplatforminterfaces too.
>
> What I'm actually not 100% sure about at this point, if target kdevgit-test
> links against kdevplatformtestshell, which has kdevplatformshell as
> link-interface-lib then does it also automatically get
> kdevplatforminterfaces because kdevplatformshell has that in its own
> link-interface-lib? In other words, are link-interface-libs "forwarded" in
> this sense?

I think they aren't.
But to make sure a small test case would help.
Something like:

add_library(foo SHARED foo.c)

add_library(bar SHARED bar.c)
target_link_libraries(bar foo)
target_link_libraries(bar LINK_INTERFACE_LIBRARIES foo)

add_library(blub SHARED blub.c)
target_link_libraries(blub bar) # will link also against foo
target_link_libraries(blub LINK_INTERFACE_LIBRARIES bar)


add_executable(hello main.c)
target_link_libraries(hello blub) # will link also to bar, but will it also 
link to foo ?


The libraries basically need just one function each, like e.g.
int foo() {return 42;} etc.

Can you please check ?

Alex
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem