Re: [CMake] Mingw64: add a statically linked library adds libstdc++ dependency

[William Zeitler]

What finally worked was:

set(CMAKE_CXX_STANDARD_LIBRARIES "-static-libgcc -static-libstd++ 
${CMAKE_CXX_STANDARD_LIBRARIES})


if(MINGW)
    set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} 
-Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive")

endif()

Thanks!

On 6/17/19 02:16, Eric Dönges wrote:

On 15.06.19 21:33, William Zeitler wrote:

In the example below, two lines are marked "COMMENT ME OUT": one in
hello_c/main.cpp and the other in hello_c/CMakeLists.txt. If you comment
these out, the reference to the hello_lib library is removed; the
project builds and the executable executes on Windows 10 without a
libstdc++ dependency. If you uncomment the two lines, the function in
the hello_lib library is linked in; the project builds, but won't
execute on Windows 10 due to the libstdc++ dependency. (Note: in
powershell it silently fails, in an old-school dos/cmd box it displays
an error message.)

I think your problem is that CMAKE_CXX_FLAGS are only used when
compiling, not linking, so your hello_lib is linked without the "-static
-static-libgcc -static-libstdc++" options and thus links against the
shared libstdc++. You could try either of the following:

1) Add a "target_link_libraries(hello_lib -static-libgcc
-static-libstdc++)".

2) Add "string(APPEND CMAKE_SHARED_LINKER_FLAGS "-static-libgcc
-static-libstdc++)" to your project. Note that this will probably need
to be done before defining any of your (library) targets. Also note that
this will link any shared library in your project with the static
libstdc++, which may or may not be what you want.

Disclaimer - I haven't tried if any of this actually solves your
problem; I just think it should.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Multiple exports for a target installation

[Shoaib Meenai]

Thank you!

When you say having an export set that the other exports then depend on, do you 
mean the COMPONENT option of the install(EXPORT) signature, or something else? 
(Sadly the project I’m working with is still on CMake 3.4.3, whose 
documentation says something very different for the COMPONENT option than the 
latest version, but I’ll cross that bridge when I get to it.)

From: Craig Scott 
Date: Saturday, June 15, 2019 at 10:43 PM
To: Shoaib Meenai 
Cc: "cmake@cmake.org" 
Subject: Re: [CMake] Multiple exports for a target installation



On Sat, Jun 15, 2019 at 9:03 PM Shoaib Meenai 
mailto:smee...@fb.com>> wrote:
Is it possible to associate a target with multiple exports? For example, if I'm 
building a project where I want to create multiple export sets, but there's 
some overlap in targets between those sets. I tried passing multiple EXPORT 
options to the install(TARGETS) signature but I just got an error: install 
TARGETS given unknown argument "EXPORT".

Typically, you'd want your export sets to not be overlapping and to contain no 
cyclic dependencies. If you have a target in multiple export sets, it suggests 
that you probably should factor out that target to a separate export set that 
other exports then depend on. That said, if you have a scenario that 
legitimately requires a target in multiple export sets, then you would need to 
use multiple install() commands to achieve this, specifying a different export 
set for each one.


--
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical 
Guide
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Why do executables link static libs that shared libs were built from?

[Paul Smith]

On Mon, 2019-06-17 at 11:43 +0200, Eric Noulard wrote:
> Yes you are right and I know that, but AFAIK when (with CMake) you
> TLL a shared lib to a static lib. You do not end up with any of the
> static lib symbol in the shared lib.

That can't be true, unless cmake is adding fancy linker options to the
command line (it doesn't :)).  The decision of what goes into the
library is up to how the linker works and what flags it's given.

However, note I said "it will have the _required_ contents" (emphasis
added).  As you noted, the .so will only pull in symbols from the .a
which are needed to link the .so.  That may not be all the symbols in
the .a, so in your test make sure you have that reference.

Alternatively you can configure the link of the shared library to use
"whole archive" mode which pulls in the entire contents of the .a
regardless of whether they are referenced.

> > I've added the static library to the creation of the shared
> > library:
> > 
> >   cc -shared -o bar.so bar.o libfoo.a
> > 
> > Now when bar.so is created it will have the required contents of
> > libfoo.a in it.
> 
> You mean that the part of libfoo.a which is actually used by some
> part of bar.o gets in bar.so or any [exported] symbol found in
> libfoo.a gets in bar.so with the same export rule?

The former (the part that is actually used).  However again, you can
force the linker to include everything, even unused symbols.

> If there is effectively no need to have static lib on the line
> because a shared lib depending on this static lib was already linked
> to it, then it ought to be suppressed and not rely on some linker
> policy to tidy up the whole set of shared and static libs.

I did come across a real problem that I don't know how to solve, caused
by this behavior.

I'm going to start a new thread about it since this one is long and
convoluted.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Specifying name of library file on CMake command line?

[Kyle Edwards]

On Mon, 2019-06-17 at 13:47 +, Osman Zakir wrote:
> I want to know how to specify the name of a library I file I want to
> link against.  How do I do this?  I wanted to build a library with a
> static runtime and static libs; it requires linking against a Boost
> library which I did build with static runtime but when I tried to
> build it, I had linker errors because the dynamic version of the
> library was used instead of the static one.  I want to somehow make
> it use the static one.  So yeah, how do I do this?  Is there a way?

Are you using the FindBoost module?

https://cmake.org/cmake/help/v3.14/module/FindBoost.html​

Kyle
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Specifying name of library file on CMake command line?

[Osman Zakir]

I want to know how to specify the name of a library I file I want to link 
against.  How do I do this?  I wanted to build a library with a static runtime 
and static libs; it requires linking against a Boost library which I did build 
with static runtime but when I tried to build it, I had linker errors because 
the dynamic version of the library was used instead of the static one.  I want 
to somehow make it use the static one.  So yeah, how do I do this?  Is there a 
way?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] getting compiler's include paths

[jl forums]

Hi,
I want to create a full tag file and for this require to know the compiler
full include path...  there is a way to had custom includes path but didn't
found any variables for the include path
for example :
$ gcc-8 -v -x c -E /dev/null
Using built-in specs.
[]
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/x86_64-linux-gnu/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
[...]

$ gcc -v -x c -E /dev/null
Using built-in specs.
[...]
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/x86_64-linux-gnu/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
[...]

I tried to


get_target_property(moggle_interface_includes FileSync
INTERFACE_INCLUDE_DIRECTORIES)
message("Moggle interface includes: ${moggle_interface_includes}")

get_target_property(motor_includes FileSync INCLUDE_DIRECTORIES)
message("MOTOR includes ${motor_includes}")

but I get

Moggle interface includes: moggle_interface_includes-NOTFOUND
MOTOR includes motor_includes-NOTFOUND


there is also some issue because cmake strip dependencies from system's
include, which means that updating a system software won't cause rebuild
and consider that the build is uptodate, causing unexpected results
seems that there is ways to workaround this :
https://stackoverflow.com/questions/7461000/handling-header-files-dependencies-with-cmake
but this is ugly... would be better to let the user choose with an option

thanks and regards
JLM
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Why do executables link static libs that shared libs were built from?

[Eric Noulard]

Le lun. 17 juin 2019 à 02:01, Paul Smith  a écrit :

> On Sun, 2019-06-16 at 21:42 +0200, Eric Noulard wrote:
> > Le dim. 16 juin 2019 à 18:26, Paul Smith  a
> > écrit :
> > > But, that's not the only way to use shared libraries.  I'm trying
> > > to collect a number of static libraries with different interfaces
> > > into a single shared library that can be linked with executables.
> >
> > Correct me if I'm wrong but I guess that if your goal is to "collect"
> > all those static libs *into* a shared lib then what you need is to
> > make your STATIC libs,  OBJECT libs and then I think you'll get what
> > you expect.
>
> Yep, I'm familiar with OBJECT libs and if I could use them they would
> give the correct behavior, you're right.  Unfortunately it's not the
> case that OBJECT libraries are completely "drop-in" replaceable for
> STATIC libraries, and they cannot be substituted in my environment.
>
> See, for one example:
> https://gitlab.kitware.com/cmake/cmake/issues/19388
>
> I am not able to rework my system comprehensively enough to remove all
> mutual references between all my current libraries.  And there are
> other issues where OBJECT libraries aren't the equivalent of STATIC
> libraries.
>

Yes right.


> > Otherwise (at least in the way CMake currently works) any symbols
> > defined in foo.a STATIC lib will *stay* in it. So in the end when you
> > link an executable using bar.so SHARED lib only (which is using
> > foo.a) then you won't have the symbol you need from foo unless foo.a
> > is added to the link line ? Am I right?
>
> No, that's not right.
>
> The visibility of symbols depends on how your code is compiled and has
> nothing to do with cmake and whether cmake links into a shared or
> static library.
>
> On POSIX systems (gcc and clang), all symbols are public by default
> regardless of whether you are compiling them for a static or shared
> library.
>
> On Windows it's all more complicated, but in my situation I've added
> the WINDOWS_EXPORT_ALL_SYMBOLS property to my libraries.
>

Yes you are right and I know that, but AFAIK when (with CMake) you TLL a
shared lib to a static lib. You do not end up with any of the static lib
symbol in the shared lib.
At least none of them are visible with nm. (I did only test that on Linux).

> But how can you do that without either:
> >
> > 1) adding the static lib to any link line (including the one using bar)
> > 2) *merging* foo.a *into* bar.so which should be what you achieve by
> > making foo an OBJECT lib.
>
> I'm not sure what you mean by "merging foo.a into bar.so": you can't
> merge something into a shared library any more than you can merge
> something into an executable.  By putting "foo" into the TLL of "bar",
> I've added the static library to the creation of the shared library:
>
>   cc -shared -o bar.so bar.o libfoo.a
>
> Now when bar.so is created it will have the required contents of
> libfoo.a in it.
>

You mean that the part of libfoo.a which is actually used by some part of
bar.o gets in bar.so
or any [exported] symbol found in libfoo.a gets in bar.so with the same
export rule?

My test showed me something different but I'll check again, I must have
done something wrong.


> > If we can agree on that, then using the current rules of CMake
> > > inheritance this implies that we can NEVER add a static library as
> > > a PUBLIC TLL for a shared library.
> >
> > Exactly my point. I understand what you say, but if ever CMake was
> > doing that you simply couldn't switch (GLOBALLY) from SHARED to
> > STATIC using
> > https://cmake.org/cmake/help/v3.14/variable/BUILD_SHARED_LIBS.html
> > is a single SHARED lib was explicitely specified.
>
> I wasn't familiar with that option, but I don't think it makes a
> difference whether the libraries are made SHARED via this option or
> whether they are made SHARED via direct specification: the behavior is
> the same.
>
> > My opinion is that CMake may handle TLL(SHARED STATIC) differently
> > than TLL(SHARED SHARED) but forbidding the first would be a major
> > headache when you want to go from STATIC to SHARED lib one step after
> > another (I have a concrete example in mind in a legacy project).
>
> I didn't say it should be forbidden!!
>
> I said that as cmake is currently implemented it doesn't make sense to
> do it, implying that cmake might want to change its behavior in this
> area to be more useful.
>

OK now I get your point, thank you for clarifying.


> However, after more investigation I see that I was wrong about how
> linkers resolve symbols at least in POSIX systems (I'm not sure about
> DLLs on Windows... I haven't gotten there yet).
>
> For some reason I remembered that a linker would prefer symbols found
> in static libraries over those found in shared libraries, but in fact
> the linker will always choose the implementation of the symbol in the
> first library it's defined in regardless of the type of library.
>

Yes that's right, note however that this behavior may vary between

Re: [CMake] Mingw64: add a statically linked library adds libstdc++ dependency

[Eric Dönges]

On 15.06.19 21:33, William Zeitler wrote:
> In the example below, two lines are marked "COMMENT ME OUT": one in
> hello_c/main.cpp and the other in hello_c/CMakeLists.txt. If you comment
> these out, the reference to the hello_lib library is removed; the
> project builds and the executable executes on Windows 10 without a
> libstdc++ dependency. If you uncomment the two lines, the function in
> the hello_lib library is linked in; the project builds, but won't
> execute on Windows 10 due to the libstdc++ dependency. (Note: in
> powershell it silently fails, in an old-school dos/cmd box it displays
> an error message.)

I think your problem is that CMAKE_CXX_FLAGS are only used when
compiling, not linking, so your hello_lib is linked without the "-static
-static-libgcc -static-libstdc++" options and thus links against the
shared libstdc++. You could try either of the following:

1) Add a "target_link_libraries(hello_lib -static-libgcc
-static-libstdc++)".

2) Add "string(APPEND CMAKE_SHARED_LINKER_FLAGS "-static-libgcc
-static-libstdc++)" to your project. Note that this will probably need
to be done before defining any of your (library) targets. Also note that
this will link any shared library in your project with the static
libstdc++, which may or may not be what you want.

Disclaimer - I haven't tried if any of this actually solves your
problem; I just think it should.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake