Re: [CMake] To avoid target_link_libraries magic
On 3/21/2011 9:42 AM, Valeriy Bykov wrote:
> I'm trying to link with static library which I've found using FIND_LIBRARY:
> MESSAGE (${LPTHREAD}) prints /home/vbykov/svn/builddeps/glibc/lib/libpthread.a
>
> Further I do the next:
> ADD_EXECUTABLE (test_atomic_lock test_atomic_lock.c)
> TARGET_LINK_LIBRARIES (test_atomic_lock ${LPTHREAD})
>
> But full path to the library turns into "-Bstatic -lpthread
> -Bdynamic" magically
What version of CMake are you using? Since 2.6 the above example
should link using the full path to the library.
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] To avoid target_link_libraries magic
I'm using CMake version 2.8.4. Furthermore I use custom ToolChain but I
don't think it is important.
On Mon, Mar 21, 2011 at 10:05:08AM -0400, Brad King wrote:
> On 3/21/2011 9:42 AM, Valeriy Bykov wrote:
> > I'm trying to link with static library which I've found using FIND_LIBRARY:
> > MESSAGE (${LPTHREAD}) prints
> > /home/vbykov/svn/builddeps/glibc/lib/libpthread.a
> >
> > Further I do the next:
> > ADD_EXECUTABLE (test_atomic_lock test_atomic_lock.c)
> > TARGET_LINK_LIBRARIES (test_atomic_lock ${LPTHREAD})
> >
> > But full path to the library turns into "-Bstatic -lpthread
> > -Bdynamic" magically
>
> What version of CMake are you using? Since 2.6 the above example
> should link using the full path to the library.
>
> -Brad
--
С уважением,
Быков Валерий
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] To avoid target_link_libraries magic
Ough, behaviour of target_link_libraries depends on -B flags I pass to
compiler. I pass it for proper compiler test made by CMake at initial stage.
Without it gcc can't link simple test program because can't find
standart libraries (-lc).
On Mon, Mar 21, 2011 at 05:12:56PM +0300, Valeriy Bykov wrote:
> I'm using CMake version 2.8.4. Furthermore I use custom ToolChain but I
> don't think it is important.
>
> On Mon, Mar 21, 2011 at 10:05:08AM -0400, Brad King wrote:
> > On 3/21/2011 9:42 AM, Valeriy Bykov wrote:
> > > I'm trying to link with static library which I've found using
> > > FIND_LIBRARY:
> > > MESSAGE (${LPTHREAD}) prints
> > > /home/vbykov/svn/builddeps/glibc/lib/libpthread.a
> > >
> > > Further I do the next:
> > > ADD_EXECUTABLE (test_atomic_lock test_atomic_lock.c)
> > > TARGET_LINK_LIBRARIES (test_atomic_lock ${LPTHREAD})
> > >
> > > But full path to the library turns into "-Bstatic -lpthread
> > > -Bdynamic" magically
> >
> > What version of CMake are you using? Since 2.6 the above example
> > should link using the full path to the library.
> >
> > -Brad
>
> --
> С уважением,
> Быков Валерий
--
С уважением,
Быков Валерий
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] To avoid target_link_libraries magic
On 3/21/2011 10:12 AM, Valeriy Bykov wrote: > I'm using CMake version 2.8.4. Furthermore I use custom ToolChain but I > don't think it is important. > > ... /home/vbykov/svn/builddeps/glibc/lib/libpthread.a It may be important actually. Is this path to libpthread.a in the implicit library search path for the toolchain? What is the full link line produced? CMake behaves a bit differently for targets in implicit link directories. Instead of using the full path it converts the library to '-lpthread' knowing that the linker will find it. This is because some toolchains substitute architecture-specific implicit link directories at the last moment. One may always use IMPORTED targets to tell CMake _exactly_ what path to use for a library: http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets#Importing_Targets See also the documentation here for why -B(static|dynamic) appear: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LINK_SEARCH_END_STATIC and a recent change I made to help folks that want static linking: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5abfb571 A version of CMake with this change is available as a nightly binary: http://www.cmake.org/files/dev/?C=M;O=D -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] To avoid target_link_libraries magic
Thanks for explanations.
It is possible to use imported targets for all libraries or
target properties but it is not convinient because I have
a lot of targets in my project.
So I'll try to describe all my problems:
I want to build all the project statically using certain version of glibc,
gcc and all other libs I need. They are situated in the folder "builddeps"
which I can simply checkout on any host and pass it's path to CMake.
I set compile option -nostdinc and specify all system and user include
directories explicitly in toolchain file. By this I can be sure that
only headers are used which I want, and no one from host system where
may be its own gcc and glibc too.
I set link option -static. It is enough to build all statically but in
command line of collect2 I've found the next (paths are shortened for
convinience):
.../builddeps/.../collect2 -m elf_x86_64 -static -o
../../../../test_atomic_lock ...builddeps/.../lib64/crt1.o
.../builddeps/.../lib64/crti.o
.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2
-L.../builddeps/.../lib/gcc
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../..
CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o
.../builddeps/glibc/lib/libpthread.a --start-group -lgcc -lgcc_eh -lc
--end-group .../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o
We can see that startup object files are used from my own gcc, but ld
itself adds -L options to search libraries paths and then uses -lgcc,
-lgcc_eh and -lc, so I am afraid that I can link with host system libraries.
Then I try to specify libraries explicitly in toolchain file:
SET (GCC_DEFAULT_LIBS "-nodefaultlibs ${BUILDDEPS}/gcc45/lib64/libstdc++.a
${BUILDDEPS}/glibc/lib/libm.a --start-group
${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a
${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a
${BUILDDEPS}/glibc/lib/libc.a --end-group ${BUILDDEPS}/glibc/lib/libpthread.a"
CACHE STRING "GCC default libs" FORCE)"
SET (CMAKE_EXE_LINKER_FLAGS "-static ${GCC_DEFAULT_LIBS}" CACHE STRING "Flags
used by the linker." FORCE)
But there is two problems as we can see from collect2 options:
.../builddeps/.../collect2 -m elf_x86_64 -static -o
../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o
.../builddeps/.../lib64/crti.o
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2
-L.../builddeps/.../lib/gcc
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../..
.../builddeps/gcc45/lib64/libstdc++.a .../builddeps/glibc/lib/libm.a
.../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a
.../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a
.../builddeps/glibc/lib/libc.a .../builddeps/glibc/lib/libpthread.a
CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o
.../builddeps/glibc/lib/libpthread.a
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o
The first is that CMake eats "--start-group" and "--end-group".
The second is CMake inserts these system libraries in the front of
libraries therefore link fails.
So I avoid this way and simply specify my own LINK_DIRECTORIES to
${BUILDDEPS}/glibc/lib, ${BUILDDEPS}/gcc45/lib64 and
${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2 in toolchain
file. Then this -L entries appear in front of those which are added by
ld and I hope I really uses libraries I need.
But then I have problem with -lpthread, which in ${BUILDDEPS}/glibc/lib
too... But! By some strange reason ${BUILDDEPS}/glibc/lib/libpthread.a
turns into -lpthread only when I specify -B${BUILDDEPS}/glibc/lib in
CMAKE_C_FLAGS. If I don't do it then CMake compiler tests fails on hosts
without installed system gcc and glibc. But on host with it all works
file:
.../builddeps/.../collect2 -m elf_x86_64 -static -o
../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o
.../builddeps/.../lib64/crti.o
.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o
-L.../builddeps/glibc/lib -L.../builddeps/glibc
-L.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2
-L.../builddeps/gcc45/bin/../lib/gcc
-L.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L.../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../..
CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o
.../builddeps/glibc/lib/libpthread.a -
Re: [CMake] To avoid target_link_libraries magic
For now I have fixed build on different hosts by forcing ithe compiler.
But I don't understand why does it work and why lib is passed by full path
now.
On Tue, Mar 22, 2011 at 12:27:10PM +0300, Valeriy Bykov wrote:
> Thanks for explanations.
>
> It is possible to use imported targets for all libraries or
> target properties but it is not convinient because I have
> a lot of targets in my project.
>
> So I'll try to describe all my problems:
> I want to build all the project statically using certain version of glibc,
> gcc and all other libs I need. They are situated in the folder "builddeps"
> which I can simply checkout on any host and pass it's path to CMake.
>
> I set compile option -nostdinc and specify all system and user include
> directories explicitly in toolchain file. By this I can be sure that
> only headers are used which I want, and no one from host system where
> may be its own gcc and glibc too.
>
> I set link option -static. It is enough to build all statically but in
> command line of collect2 I've found the next (paths are shortened for
> convinience):
> .../builddeps/.../collect2 -m elf_x86_64 -static -o
> ../../../../test_atomic_lock ...builddeps/.../lib64/crt1.o
> .../builddeps/.../lib64/crti.o
> .../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2
> -L.../builddeps/.../lib/gcc
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../..
> CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o
> .../builddeps/glibc/lib/libpthread.a --start-group -lgcc -lgcc_eh -lc
> --end-group .../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o
>
> We can see that startup object files are used from my own gcc, but ld
> itself adds -L options to search libraries paths and then uses -lgcc,
> -lgcc_eh and -lc, so I am afraid that I can link with host system libraries.
>
> Then I try to specify libraries explicitly in toolchain file:
> SET (GCC_DEFAULT_LIBS "-nodefaultlibs ${BUILDDEPS}/gcc45/lib64/libstdc++.a
> ${BUILDDEPS}/glibc/lib/libm.a --start-group
> ${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a
> ${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a
> ${BUILDDEPS}/glibc/lib/libc.a --end-group
> ${BUILDDEPS}/glibc/lib/libpthread.a" CACHE STRING "GCC default libs" FORCE)"
> SET (CMAKE_EXE_LINKER_FLAGS "-static ${GCC_DEFAULT_LIBS}" CACHE STRING "Flags
> used by the linker." FORCE)
>
> But there is two problems as we can see from collect2 options:
> .../builddeps/.../collect2 -m elf_x86_64 -static -o
> ../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o
> .../builddeps/.../lib64/crti.o
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2
> -L.../builddeps/.../lib/gcc
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64
> -L.../builddeps/.../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../..
> .../builddeps/gcc45/lib64/libstdc++.a .../builddeps/glibc/lib/libm.a
> .../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc.a
> .../builddeps/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/libgcc_eh.a
> .../builddeps/glibc/lib/libc.a .../builddeps/glibc/lib/libpthread.a
> CMakeFiles/test_atomic_lock.dir/test_atomic_lock.c.o
> .../builddeps/glibc/lib/libpthread.a
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtend.o
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/../../../../lib64/crtn.o
>
> The first is that CMake eats "--start-group" and "--end-group".
> The second is CMake inserts these system libraries in the front of
> libraries therefore link fails.
>
> So I avoid this way and simply specify my own LINK_DIRECTORIES to
> ${BUILDDEPS}/glibc/lib, ${BUILDDEPS}/gcc45/lib64 and
> ${BUILDDEPS}/gcc45/lib/gcc/x86_64-unknown-linux-gnu/4.5.2 in toolchain
> file. Then this -L entries appear in front of those which are added by
> ld and I hope I really uses libraries I need.
>
> But then I have problem with -lpthread, which in ${BUILDDEPS}/glibc/lib
> too... But! By some strange reason ${BUILDDEPS}/glibc/lib/libpthread.a
> turns into -lpthread only when I specify -B${BUILDDEPS}/glibc/lib in
> CMAKE_C_FLAGS. If I don't do it then CMake compiler tests fails on hosts
> without installed system gcc and glibc. But on host with it all works
> file:
> .../builddeps/.../collect2 -m elf_x86_64 -static -o
> ../../../../test_atomic_lock .../builddeps/.../lib64/crt1.o
> .../builddeps/.../lib64/crti.o
> .../builddeps/gcc45/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.5.2/crtbeginT.o
> -L.../builddeps/glibc/lib -L.../builddeps/glibc
> -L.../builddeps/gcc
Re: [CMake] To avoid target_link_libraries magic
Zitat von Valeriy Bykov : So I'll try to describe all my problems: I want to build all the project statically using certain version of glibc, gcc and all other libs I need. They are situated in the folder "builddeps" which I can simply checkout on any host and pass it's path to CMake. I set compile option -nostdinc and specify all system and user include directories explicitly in toolchain file. By this I can be sure that only headers are used which I want, and no one from host system where may be its own gcc and glibc too. You want the --sysroot gcc option. HS ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] To avoid target_link_libraries magic
On 03/22/2011 05:27 AM, Valeriy Bykov wrote: > I want to build all the project statically using certain version of glibc, > gcc and all other libs I need. They are situated in the folder "builddeps" > which I can simply checkout on any host and pass it's path to CMake. The easiest way to ensure a static link is to use a recent CMake nightly build: http://www.cmake.org/files/dev/?C=M;O=D and set this on your targets: set_property(TARGET myexe PROPERTY LINK_SEARCH_START_STATIC 1) Then no -Bdynamic or -Bstatic options will show if you don't give any shared libraries to target_link_libraries. This feature will be included in the next release of CMake. > SET (CMAKE_EXE_LINKER_FLAGS ...) > > The second is CMake inserts these system libraries in the front of > libraries therefore link fails. The CMAKE_EXE_LINKER_FLAGS is not the place to put libraries for the end of the link line. It is meant for the beginning to have things like -m64. > So it's not obvious in which cases transforming will be applied. When CMake first runs the ABI check it detects which library search directories appear in the default link line. Look at CMakeFiles/CMakeCCompiler.cmake to see them (CMAKE_C_IMPLICIT_LINK_DIRECTORIES). Libraries in these directories will not be passed by full path unless you use an imported target. When you put -B/some/path in CMAKE_C_FLAGS then this ends up in the detected implicit list because the front-end converts it to -L/some/path when invoking the linker. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
