[CMake] CMAKE_EXE_LINKER_FLAGS for shared libraries?

Use CMAKE_SHARED_LINKER_FLAGS. Strangely, this family of variables is
missing from the docs...

Michael

David Cole

2011-12-12 20:10:26 UTC

Apparently, they are undocumented, but there are also:

CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS (and their
per-config variants) for SHARED and MODULE library targets as well.

Use CMAKE_SHARED_LINKER_FLAGS instead.

HTH,
David

Post by Robert Dailey
I need a version of CMAKE_EXE_LINKER_FLAGS for shared libraries. I need to
specify /NODEFAULTLIB for a shared library (DLL) that I'm building, but it
doesn't seem that CMAKE_EXE_LINKER_FLAGS is used by shared library projects
generated by CMake for visual studio.
Any suggestions?
---------
Robert Dailey
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.cmake.org/Wiki/CMake_FAQ
http://www.cmake.org/mailman/listinfo/cmake

Robert Dailey

2011-12-12 20:13:44 UTC

Post by David Cole
CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS (and their
per-config variants) for SHARED and MODULE library targets as well.
Use CMAKE_SHARED_LINKER_FLAGS instead.

Thanks for the information guys. I'm having a minor problem with these
variables though.

Here is how I use it:

set( CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS}
/NODEFAULTLIB:\"${lib}\" )

Prior to calling the set above, the shared linker flags look like this:

/STACK:10000000 /machine:X86

After calling the set above, it looks like this:

/STACK:10000000 /machine:X86 ;/NODEFAULTLIB:"LIBC"

For some reason a semi-colon is being inserted prior to the /NODEFAULTLIB
part. I don't know why this is happening but visual studio is complaining
about it. Any reason why this is happening? Thanks.

Robert Dailey

2011-12-12 20:15:15 UTC

Post by David Cole
CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS (and their
per-config variants) for SHARED and MODULE library targets as well.
Use CMAKE_SHARED_LINKER_FLAGS instead.

Thanks for the information guys. I'm having a minor problem with these
variables though.
set( CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS}
/NODEFAULTLIB:\"${lib}\" )
/STACK:10000000 /machine:X86
/STACK:10000000 /machine:X86 ;/NODEFAULTLIB:"LIBC"
For some reason a semi-colon is being inserted prior to the /NODEFAULTLIB
part. I don't know why this is happening but visual studio is complaining
about it. Any reason why this is happening? Thanks.

Actually I just realized it is probably putting the semi-colon there
because it thinks I'm trying to create a list. I guess I need to create a
temp variable and call list(APPEND) on it first, then set
CMAKE_SHARED_LINKER_FLAGS to the temp list variable? Kind of messy...

David Cole

2011-12-12 20:20:49 UTC

Post by David Cole
CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS (and their
per-config variants) for SHARED and MODULE library targets as well.
Use CMAKE_SHARED_LINKER_FLAGS instead.

Actually I just realized it is probably putting the semi-colon there because
it thinks I'm trying to create a list. I guess I need to create a temp
variable and call list(APPEND) on it first, then set
CMAKE_SHARED_LINKER_FLAGS to the temp list variable? Kind of messy...

These are space separated in the final value, and passed to the linker
as is, so you should set it like this:

set( CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}
/NODEFAULTLIB:\"${lib}\"" )

(Double-quote the whole thing, so the space is embedded in the string,
rather than used by cmake as an argument separator for the set
command.)

HTH,
David

Michael Wild

2011-12-12 20:20:59 UTC

Post by David Cole
CMAKE_SHARED_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS (and their
per-config variants) for SHARED and MODULE library targets as well.
Use CMAKE_SHARED_LINKER_FLAGS instead.
Thanks for the information guys. I'm having a minor problem with these
variables though.
set( CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS}
/NODEFAULTLIB:\"${lib}\" )
/STACK:10000000 /machine:X86
/STACK:10000000 /machine:X86 ;/NODEFAULTLIB:"LIBC"
For some reason a semi-colon is being inserted prior to the
/NODEFAULTLIB part. I don't know why this is happening but visual studio
is complaining about it. Any reason why this is happening? Thanks.

That's how CMake works.

set(VAR val1 val2 val3)

defines a *list* where the elements are separated by a semi-colon (;).
To prevent that, quote the assignment:

set(VAR "val1 val2 val3")

Michael

Robert Dailey

2011-12-12 22:10:37 UTC

Another issue...

At what point is it most important for the values of
CMAKE_SHARED_LINK_FLAGS to exist? I set the value of this variable before
my call to add_library(), however after that at some point the flags will
get reverted because I'm stepping out of function scope. Does it need to
exist up to the end of the current cmake script? My flow is basically this
(pseudo call stack):

Enter CMakeLists.txt
- Call define_project() function (in a separate cmake module)
- - Call ignore_libs() function
- - - Set CMAKE_SHARED_LINK_FLAGS with PARENT_SCOPE
- - Call create_target() function
- - - Call add_library() command
Leave CMakeLists.txt

I've done some testing and I find that before the call to add_library(), my
flags are setup properly in the CMAKE_SHARED_LINK_FLAGS variable.

---------
Robert Dailey

Post by Michael Wild

That's how CMake works.
set(VAR val1 val2 val3)
defines a *list* where the elements are separated by a semi-colon (;).
set(VAR "val1 val2 val3")
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.cmake.org/Wiki/CMake_FAQ
http://www.cmake.org/mailman/listinfo/cmake

Robert Dailey

2011-12-12 22:11:23 UTC

I forgot to say that the main issue is that my /NODEFAULTLIB link flag
isn't showing up in visual studio.

---------
Robert Dailey

Post by Robert Dailey
Another issue...
At what point is it most important for the values of
CMAKE_SHARED_LINK_FLAGS to exist? I set the value of this variable before
my call to add_library(), however after that at some point the flags will
get reverted because I'm stepping out of function scope. Does it need to
exist up to the end of the current cmake script? My flow is basically this
Enter CMakeLists.txt
- Call define_project() function (in a separate cmake module)
- - Call ignore_libs() function
- - - Set CMAKE_SHARED_LINK_FLAGS with PARENT_SCOPE
- - Call create_target() function
- - - Call add_library() command
Leave CMakeLists.txt
I've done some testing and I find that before the call to add_library(),
my flags are setup properly in the CMAKE_SHARED_LINK_FLAGS variable.
---------
Robert Dailey

Post by Michael Wild

Robert Dailey

2011-12-12 22:39:17 UTC

I have attached a small CMake project that reproduces the issue I'm
referring to. Please take a look :)

---------
Robert Dailey

Post by Robert Dailey
I forgot to say that the main issue is that my /NODEFAULTLIB link flag
isn't showing up in visual studio.
---------
Robert Dailey

studio

Post by David Cole
is complaining about it. Any reason why this is happening? Thanks.

Michael Wild

2011-12-13 05:26:47 UTC

It needs to exist **at the end** of the CMakeLists.txt file containing
the target. If you don't want to do that (or can't, as in your case),
you can use the LINK_FLAGS target property instead.

HTH

Michael

On Mon, Dec 12, 2011 at 2:10 PM, David Cole
CMAKE_SHARED_LINKER_FLAGS and

CMAKE_MODULE_LINKER_FLAGS (and their

per-config variants) for SHARED and MODULE library

targets as well.

Use CMAKE_SHARED_LINKER_FLAGS instead.
Thanks for the information guys. I'm having a minor

problem with these

variables though.
set( CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS}
/NODEFAULTLIB:\"${lib}\" )
Prior to calling the set above, the shared linker flags
/STACK:10000000 /machine:X86
/STACK:10000000 /machine:X86 ;/NODEFAULTLIB:"LIBC"
For some reason a semi-colon is being inserted prior to the
/NODEFAULTLIB part. I don't know why this is happening but

visual studio

is complaining about it. Any reason why this is happening?

Thanks.
That's how CMake works.
set(VAR val1 val2 val3)
defines a *list* where the elements are separated by a
semi-colon (;).
set(VAR "val1 val2 val3")
Michael
--
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.cmake.org/Wiki/CMake_FAQ
http://www.cmake.org/mailman/listinfo/cmake

Robert Dailey

2011-12-13 19:09:50 UTC

Thanks for the info. It's a bit disappointing that it doesn't work like I
expect. The CMAKE_MFC_FLAG should work as you say the link flags should,
but it does not. As long as CMAKE_MFC_FLAG is set before I create my
target, it works. Since CMAKE_SHARED_LINK_FLAGS does not work the same, I
consider this a bug. There is no reason for it to exist up to the end of
the file... it should only exist up to the call to create the target. For
example, if I want to have 2 calls to add_library() in the same file, but
specify link flags differently for each, how am I expected to do this
without using the target specific property?

---------
Robert Dailey

Post by Michael Wild
It needs to exist **at the end** of the CMakeLists.txt file containing
the target. If you don't want to do that (or can't, as in your case),
you can use the LINK_FLAGS target property instead.
HTH
Michael

On Mon, Dec 12, 2011 at 2:10 PM, David Cole
CMAKE_SHARED_LINKER_FLAGS and

CMAKE_MODULE_LINKER_FLAGS (and their

per-config variants) for SHARED and MODULE library

targets as well.

Use CMAKE_SHARED_LINKER_FLAGS instead.
Thanks for the information guys. I'm having a minor

problem with these

visual studio

is complaining about it. Any reason why this is happening?

David Cole

2011-12-13 20:21:05 UTC

Post by Robert Dailey
Thanks for the info. It's a bit disappointing that it doesn't work like I
expect. The CMAKE_MFC_FLAG should work as you say the link flags should, but
it does not. As long as CMAKE_MFC_FLAG is set before I create my target, it
works. Since CMAKE_SHARED_LINK_FLAGS does not work the same, I consider this
a bug. There is no reason for it to exist up to the end of the file... it
should only exist up to the call to create the target. For example, if I
want to have 2 calls to add_library() in the same file, but specify link
flags differently for each, how am I expected to do this without using the
target specific property?

You're not expected to do that. You should use the target property in
that case. That's what they're there for.

Or use sub-directory organization to have one target per sub-dir, and
then set the variable appropriately in each sub-dir's CMakeLists file.

And, there is a reason for it to exist up to the end of the file: it's
called backwards compatibility, and we take it pretty seriously.

The fact is that some variables are examined at configure-time, while
CMake is processing add_executable and add_library calls, and all the
other myriad commands that are affected by variables values, ...

... and some variables are examined later at generate-time, *after*
CMake is done processing the commands, (in other words, "at the end of
the file").

So: this particular case may be considered a bug by some, and a
feature by others. Personally, I'm not sure what side of that fence to
fall on.

However, the primary purpose of this mailing list is to try to show
you how you can do what you want to do with *existing* CMake. We also
like to discuss options and future plans here.

If you would like to report this as a bug, please feel free to add a
bug report to the bug tracker.

Thanks,
David

Post by Robert Dailey
---------
Robert Dailey

Post by Robert Dailey
I have attached a small CMake project that reproduces the issue I'm
referring to. Please take a look :)
---------
Robert Dailey
I forgot to say that the main issue is that my /NODEFAULTLIB link
flag isn't showing up in visual studio.
---------
Robert Dailey
Another issue...
At what point is it most important for the values of
CMAKE_SHARED_LINK_FLAGS to exist? I set the value of this
variable before my call to add_library(), however after that at
some point the flags will get reverted because I'm stepping out
of function scope. Does it need to exist up to the end of the
current cmake script? My flow is basically this (pseudo call
Enter CMakeLists.txt
- Call define_project() function (in a separate cmake module)
- - Call ignore_libs() function
- - - Set CMAKE_SHARED_LINK_FLAGS with PARENT_SCOPE
- - Call create_target() function
- - - Call add_library() command
Leave CMakeLists.txt
I've done some testing and I find that before the call to
add_library(), my flags are setup properly in the
CMAKE_SHARED_LINK_FLAGS variable.
---------
Robert Dailey
> On Mon, Dec 12, 2011 at 2:10 PM, David Cole
>
>
> CMAKE_SHARED_LINKER_FLAGS and
CMAKE_MODULE_LINKER_FLAGS (and their
> per-config variants) for SHARED and MODULE library
targets as well.
>
> Use CMAKE_SHARED_LINKER_FLAGS instead.
>
>
> Thanks for the information guys. I'm having a minor
problem with these
> variables though.
>
>
> set( CMAKE_SHARED_LINKER_FLAGS
${CMAKE_SHARED_LINKER_FLAGS}
> /NODEFAULTLIB:\"${lib}\" )
>
> Prior to calling the set above, the shared linker flags
>
> /STACK:10000000 /machine:X86
>
>
> /STACK:10000000 /machine:X86 ;/NODEFAULTLIB:"LIBC"
>
> For some reason a semi-colon is being inserted prior to
the
> /NODEFAULTLIB part. I don't know why this is happening but
visual studio
> is complaining about it. Any reason why this is happening?
Thanks.
>
That's how CMake works.
set(VAR val1 val2 val3)
defines a *list* where the elements are separated by a
semi-colon (;).
set(VAR "val1 val2 val3")
Michael
--
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.cmake.org/Wiki/CMake_FAQ
http://www.cmake.org/mailman/listinfo/cmake

--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
http://www.cmake.org/Wiki/CMake_FAQ
http://www.cmake.org/mailman/listinfo/cmake

Michael Hertling

2011-12-13 22:19:06 UTC

You're not expected to do that. You should use the target property in
that case. That's what they're there for.
Or use sub-directory organization to have one target per sub-dir, and
then set the variable appropriately in each sub-dir's CMakeLists file.
And, there is a reason for it to exist up to the end of the file: it's
called backwards compatibility, and we take it pretty seriously.
The fact is that some variables are examined at configure-time, while
CMake is processing add_executable and add_library calls, and all the
other myriad commands that are affected by variables values, ...
... and some variables are examined later at generate-time, *after*
CMake is done processing the commands, (in other words, "at the end of
the file").
So: this particular case may be considered a bug by some, and a
feature by others. Personally, I'm not sure what side of that fence to
fall on.
However, the primary purpose of this mailing list is to try to show
you how you can do what you want to do with *existing* CMake. We also
like to discuss options and future plans here.
If you would like to report this as a bug, please feel free to add a
bug report to the bug tracker.

As for me, I wouldn't consider it as a bug, but it should perhaps be
mentioned in the documentation which variables undergo this kind of
lazy evaluation, i.e. configure-time vs. generate-time evaluation.

"This variable is not evaluated until the generation takes place,
so the value at the end of the CMakeLists.txt will be in effect."

Regards,

Michael

On Mon, Dec 12, 2011 at 2:10 PM, David Cole
CMAKE_SHARED_LINKER_FLAGS and

CMAKE_MODULE_LINKER_FLAGS (and their

per-config variants) for SHARED and MODULE library

targets as well.

Use CMAKE_SHARED_LINKER_FLAGS instead.
Thanks for the information guys. I'm having a minor

problem with these

variables though.
set( CMAKE_SHARED_LINKER_FLAGS

${CMAKE_SHARED_LINKER_FLAGS}

/NODEFAULTLIB:\"${lib}\" )
Prior to calling the set above, the shared linker flags
/STACK:10000000 /machine:X86
/STACK:10000000 /machine:X86 ;/NODEFAULTLIB:"LIBC"
For some reason a semi-colon is being inserted prior to

the

/NODEFAULTLIB part. I don't know why this is happening but

visual studio

is complaining about it. Any reason why this is happening?

Thanks.
That's how CMake works.
set(VAR val1 val2 val3)
defines a *list* where the elements are separated by a
semi-colon (;).
set(VAR "val1 val2 val3")
Michael

Michael Hertling

2011-12-16 10:28:52 UTC

Post by Michael Hertling

You're not expected to do that. You should use the target property in
that case. That's what they're there for.
Or use sub-directory organization to have one target per sub-dir, and
then set the variable appropriately in each sub-dir's CMakeLists file.
And, there is a reason for it to exist up to the end of the file: it's
called backwards compatibility, and we take it pretty seriously.
The fact is that some variables are examined at configure-time, while
CMake is processing add_executable and add_library calls, and all the
other myriad commands that are affected by variables values, ...
... and some variables are examined later at generate-time, *after*
CMake is done processing the commands, (in other words, "at the end of
the file").
So: this particular case may be considered a bug by some, and a
feature by others. Personally, I'm not sure what side of that fence to
fall on.
However, the primary purpose of this mailing list is to try to show
you how you can do what you want to do with *existing* CMake. We also
like to discuss options and future plans here.
If you would like to report this as a bug, please feel free to add a
bug report to the bug tracker.

As for me, I wouldn't consider it as a bug, but it should perhaps be
mentioned in the documentation which variables undergo this kind of
lazy evaluation, i.e. configure-time vs. generate-time evaluation.
"This variable is not evaluated until the generation takes place,
so the value at the end of the CMakeLists.txt will be in effect."

Alternatively, one might add a brief description of the two evaluation
kinds right beneath [1] but before [2] and mark the generation-time-
evaluated variables with a short tag afterwards.

Regards,

Michael

Post by Michael Hertling
[1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Variables
[2] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_VariablesThatChangeBehavior