[CMake] link problem with a name changed target

Ingrid Kemgoum ingrid.kemgoum at gmail.com
Fri Aug 22 04:42:55 EDT 2008


thaks a lot.
i try to modify hadly the link.txt file of my exec and nothing worked.
when i add to the target libxsystemd, cmake fail to find it but when i add
libxsystem, cmake choose itself the debug name of libxsystem (as it's a
cmake target ) and now everythink rocks!!!!!!!!!!!!!!!!

thanks again

2008/8/22 Yuri V. Timenkov <ytimenkov at parallels.com>

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


More information about the CMake mailing list