To avoid target_link_libraries magic

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

To avoid target_link_libraries magic

Valeriy Bykov
Hello.

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, and in the line of collect2 options appears:
-static -o test_atomic_lock -Bstatic -lpthread -Bdynamic --start-group -lgcc -lgcc_eh -lc --end-group
(I've omitted a lot of other libraries and object files). Therefore
-Bdynamic applies to -lgcc and other libraries, which I want to link statically.

So can I adjust this target_link_libraries behaviour and pass plainly
what I want?

--
Best regards,
Valeriy Bykov
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Valeriy Bykov
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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Valeriy Bykov
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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Brad King
In reply to this post by Valeriy Bykov
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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Valeriy Bykov
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 -rpath .../builddeps/glibc/lib --start-group -lgcc -lgcc_eh -lc --end-group .../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

Do you see? There is -L.../builddeps/glibc/lib and
.../builddeps/glibc/lib/libpthread.a. So it's not obvious in which cases
transforming will be applied.

On Mon, Mar 21, 2011 at 10:30:58AM -0400, Brad King wrote:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Valeriy Bykov
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/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 -rpath .../builddeps/glibc/lib --start-group -lgcc -lgcc_eh -lc --end-group .../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
>
> Do you see? There is -L.../builddeps/glibc/lib and
> .../builddeps/glibc/lib/libpthread.a. So it's not obvious in which cases
> transforming will be applied.
>
> On Mon, Mar 21, 2011 at 10:30:58AM -0400, Brad King wrote:
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Hendrik Sattler
In reply to this post by Valeriy Bykov
Zitat von Valeriy Bykov <[hidden email]>:
> 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
Reply | Threaded
Open this post in threaded view
|

Re: To avoid target_link_libraries magic

Brad King
In reply to this post by Valeriy Bykov
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