[CMake] link problem with a name changed target

[Yuri V. Timenkov]

On Friday 22 August 2008 11:18:50 Ingrid Kemgoum wrote:
> 2008/8/21 Yuri V. Timenkov <ytimenkov at parallels.com>
>
> > On Thursday 21 August 2008 17:27:36 Ingrid Kemgoum wrote:
> > > HI,
> > > i'm building a project with 3 targets in Linux. each target has a
> >
> > different
> >
> > > name when in debug.
> > >
> > > the executable i want to link to the 2 libraries fail to find thoz libs
> > > when i'm in debug (not the case in release, everything's good).
> > >
> > > here is the CMakeLists of the executable
> >
> > Very strange file, but...
> >
> > > cmake_minimum_required(VERSION 2.6)
> > > include_directories (${ORIGIN}/tst_xsystem/../../../import/xdefaut/inc
> > > ${ORIGIN}/tst_xsystem/../../../inc
> > > ${ORIGIN}/tst_xsystem/../../../imports/xdefaut/inc )
> > > set(sources ${ORIGIN}/tst_xsystem/../../../src/tst_xsystem.c
> > > ${ORIGIN}/tst_xsystem/../../../imports/xdefaut/inc/x_defaut.h)
> >
> > BTW: CMake defines ${CMAKE_SOURCE_DIR} and ${CMAKE_CURRENT_SOURCE_DIR}
> > variables. I suppose they can be used instead of origin. The whole code
> > will
> > look cleaner...
>
> i know the existence of those variables. but in this case i can't use them.
> i'm building a triple out-of-source project. The project files are in
> ${ORIGIN}, the cmake files are in a different directory and the binaries
> anf libraries obtained are in an order directory.
> i can't do it differently, it's how the enterprise want it to be.
Yes, it's bad and I'm aware of such cases. I'm happy that I convinced my 
management to use full advantages of cmake build process and completely drop 
Makefiles and vcproj's from CVS.

>
> > > if (CMAKE_HOST_WIN32)
> > >   set (sources ${sources} ${ORIGIN}/tst_xsystem/tst_xsystem.rc)
> > > endif(CMAKE_HOST_WIN32)
> > > if (CMAKE_HOST_UNIX)
> > >   set (sources ${sources} ${DEST}/tst_xsystem/tst_xsystem.c)
> > > endif(CMAKE_HOST_UNIX)
> > > add_executable(tst_xsystem ${sources})
> > > add_dependencies(tst_xsystem  libxsystem libxsystem_so)
> >
> > I'm not sure if this works for not cmake targets.
>
> They are cmake targets so it works
>
> > > if (${CONFIG} MATCHES "DEBUG")
> > >  target_link_libraries(tst_xsystem libxsystemd_so libxsystemd pthread
> > > rt
> >
> > dl
> >
> > > nsl) ###########"
> > > else(${CONFIG} MATCHES "DEBUG")
> > >  target_link_libraries(tst_xsystem libxsystem_so libxsystem pthread rt
> > > dl nsl)
> > > endif(${CONFIG} MATCHES "DEBUG")
> >
> > Why not use following instead:
> > set(libxsystm_LIBS debug libxsystemd optimized libxsystem)
> > set(libxsystem_so_LIBS debug libxsystemd_so optimized libxsystem_so)
> > target_link_libraries(tst_xsystem libxsystem_so
> >        ${libxsystm_LIBS}
> >        ${libxsystem_so_LIBS}
> >        pthread rt dl)
> >
> > Using ${CONFIG} is not portable, it will not work in generators, which
> > support
> > multiple configurations.
>
> i've taken it into account thanks (but no changes)
>
> > > set_target_properties(tst_xsystem PROPERTIES
> > >  PREFIX ""
> > >  DEBUG_OUTPUT_NAME "tst_xsystemd"
> > >  LINKER_LANGUAGE "CXX"
> > >  LINK_FLAGS_RELEASE ${linkexecutablerel}
> > > )
> >
> > Why not use DEBUG_POSTFIX "d"?
>
> i can't use the postfix because the naming system of the company is not
> that simple. postfix will work for executables and static libs but shared
> ones are named lib_so and the debug name libd_so
>
> > > the problem is in the red line (marqued ########).
> > > names are differents and the error is
> > >
> > > Linking CXX executable
> >
> > /home/ikemgoum/workspace/reference/xsystem/code/os/linux_redhatEL4_0_i386
> >__
> >
> > >gcc3_4/bin/tst_xsystemd /usr/bin/ld: can not find -llibxsystemd
> >
> > If libxsystemd is a target generated by cmake in the same project, you
> > don't
> > need to bother with release/debug switches at all (I suppose).
>
> it is what i supposed to but obviously it's not. libxsystem is a cmake
> target, static lib, and it's debug output name is libxsystemd
>
> > Next, your library should be named liblibxsystemd.so if you use
> > DEBUG_OUTPUT_NAME you may break CMake rules which generate proper library
> > name.
>
> i dont know how but this works in windows!! the debug name is found. i try
> to add the cmake_library_path with the path of the output lib path but no
> changes.
> i still have the same problem.
Compare output names of debug and release. Do your debug library generated at 
all? The following makefile works in my case:

project(test)

set(BUILD_SHARED_LIBS OFF)

add_library(mylib mylib.cpp)
target_link_libraries(mylib dl)
set_target_properties(mylib PROPERTIES DEBUG_OUTPUT_NAME "libsystemd")

add_executable(myapp myapp.cpp)
target_link_libraries(myapp ${myapp_LIBS})

cmake -DCMAKE_BUILD_TYPE=debug ..
=(%:~/test/build)=- make
[ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.o
Linking CXX static library liblibsystemd.a
[ 50%] Built target mylib
[100%] Building CXX object CMakeFiles/myapp.dir/myapp.o
Linking CXX executable myapp
[100%] Built target myapp
And the myapp generated with command line:

/usr/bin/c++   -g   CMakeFiles/myapp.dir/myapp.o  -o myapp -rdynamic -
L/home/ytimenkov/test/build liblibsystemd.a -ldl

Note, that cmake uses full paths (not -l notation).
>
> if you have any idea thanks for help, very much.
>
> > > am i missing something?
> >
> > Too many places where the problem could be. But looking at your code, I
> > can say that you try to use CMake in wrong way. While used properly,
> > cmake makes
> > many things much simpler.
> >
> > > thanks for help