[CMake] link problem with a name changed target

[Ingrid Kemgoum]

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.



>
>
> > 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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20080822/5d048eb7/attachment.htm>