How do I add linker-flags "DEF" and "NODEFAULTLIB" to vs2012 project via CMAKE?
You can append them to CMAKE_EXE_LINKER_FLAGS:
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS} /DEF:my_defs.def /NODEFAULTLIB")
endif()
The general way is to add linker flags to CMAKE_xxx_LINKER_FLAGS, yes. However in case of CMAKE_SHARED_LINKER_FLAGS and /DEF: parameter, there is a special case that made me run into trouble.
If you already use CMAKE_EXPORT_ALL_SYMBOLS (CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS) then the /DEF: parameter will not appear in the linking command, even if you specified it in CMAKE_SHARED_LINKER_FLAGS.
This is because MSVC linker accepts only one /DEF: parameter, and CMake does not want to override the existing one: /DEF:<build_path>/exports.def (which is added due to CMAKE_EXPORT_ALL_SYMBOLS) with the one which you specify in the CMAKE_SHARED_LINKER_FLAGS.
You can use also CMAKE_CXX_STANDARD_LIBRARIES. It adds arbitrary linker flags without checking them, but it adds them into the middle of the linking command before the /DEF:<build_path>/exports.def so that the latter won't get overridden.
The full discussion of this case here: https://cmake.org/pipermail/cmake-developers/2019-November/031274.html.
Related
I have a cmake project that is part of some larger environment.
There are some cmake makros/functions that I have to use to set up my project.
At some point they add a compile flag:
TARGET_COMPILE_OPTIONS (${name} PUBLIC "$<$<CONFIG:Release>:/GL>")
however, i want to remove this flag afterwards because it causes some inconvenience in my project.
But there seems to be a bug in cmake:
I tried to to remove the flags from the INTERFACE_COMPILE_OPTIONS and COMPILE_OPTIONS (this is there target_compile_options adds the options according to cmake doku ).
message commands before and after the removal shows the success but the generated vcxproj file still contains the
<WholeProgramOptimization>true</WholeProgramOptimization>
in the <ItemDefinitionGroup><ClCompile> section.
So it seems that adding the /GL flags triggers some internal state change that can not be removed afterwards. (if i remove the addition of that flag in the macro I have to call, then the WholeProgramOptimization node is not added to the vcxproj)
Did I miss something?
I can just add a /GL- as an option but then I get a lot of D9025 warnings (override /GL with /GL-)
(tested with cmake 3.15 and 3.13)
It turns out, that the problem is that the cmake scripts I have to use sets the optimizer settings with PUBLIC as scope
TARGET_COMPILE_OPTIONS (${name} PUBLIC "$<$<CONFIG:Release>:/GL>")`
^^^^^^
Another dependency of my project uses the same function and gets this flag into its INTERFACE_COMPILE_OPTIONS and my project inherits this option without possibility to remove it.
The only way seems to be to get the common scripts fixed to use PRIVATE scope instead. This would be more logical, since its an internal target property that does not have any implications to the consumer.
How can I specify where my libs live when building examples, or even writing new projects that use rust-sfml? I currently have both SFML and CSFML installed in /usr/local/{include,lib,share} as opposed to /usr/{include,lib,share}.
Is there a flag in cargo I can apply that will set the include/library path accordingly? Something like cargo build --lib=/usr/local/lib --include=/usr/local/include.
here is the rust-sfml page.
Each library that links against C libraries needs to support the appropriate linker parameters, including finding the library itself. It appears that there is an open pull request that adds support for specifying the install path to rust-sfml.
Specifically, Cargo allows specifying a build script. The build script communicates to Cargo by printing items to standard out. Two of those values that are interesting in this case are:
rustc-link-lib— indicates that the specified value should be passed to the compiler as a -l flag.
rustc-link-search — indicates the specified value should be passed to the compiler as a -L flag.
I'm new to platform builder, this might be obvious..
I'm working on wince6.0.
I've looked everywhere, didn't find how to add flags to the compilation of the image.
I've noticed there are many flags which are specific to ARM:
http://207.46.16.248/en-us/library/ee479941%28WinEmbedded.60%29.aspx
/QRArch
/QRimplicit-import-
/QRinterwork-return
/QRxscale
/QRxscalesched
/QRthumb
How do I add them to the build and which ones take parameters (and what are they)?
Are there any general flags too? what are they?
Thank you
Apparently, you need to do two things:
Go to project properties
Add environment variable named "cl" with value such as the following or a subset of them:
/QRArch
/QRimplicit-import-
/QRinterwork-return
/QRxscale
/QRxscalesched
/QRthumb
Afterwards, you edit the sources.cmn located in the BSP folder, adding:
CDEFINES=$(CDEFINES) <the flags you picked above>
For example if I wanted to use /QRArch4 and /QRimplicit-import-
The cl variable value would be /QRArch4 /QRimplicit-import-
and the line added to the sources is:
CDEFINES=$(CDEFINES) /QRArch4 /QRimplicit-import-
I need to conditionally compile some code based on the presence of a library. Seems like this should be easy with autoconf/automake but I can't figure it out.
For example, if there is a PNG library present, I want to include code to use it. My configure.ac has:
AC_CHECK_LIB([png], [png_create_write_struct_2])
and my Makefile.am has:
if USE_LIBPNG
libdev_la_SOURCES += png.c
endif
(which adds png.c to the list of sources for libdev so it gets compiled).
An automake conditional like USE_LIBPNG requires the conditional be defined in configure.ac, so i need:
AM_CONDITIONAL([USE_LIBPNG], [test SOMETHINGOROTHER])
The question is, what can test SOMETHINGOROTHER be? What does AC_CHECK_LIB define that I can test for?
AC_CHECK_LIB's default behavior is to define a symbol (in config.h) which can be used in source code, but that doesn't help the Makefile since the AM_CONDITIONAL needs a shell test
I tried overriding the default AC_CHECK_LIB behavior like so:
AC_CHECK_LIB([png], [png_create_write_struct_2], [HAS_LIBPNG=1])
after which I could test for it:
AM_CONDITIONAL([USE_LIBPNG], [test "x$HAS_LIBPNG" = "x1"])
This is ugly, but works for the Makefile... but creates a new problem: since it discards the original AC_CHECK_LIB behavior, and I no longer get a symbol added to config.h, which I need.
I must be missing something basic, or possible Doing It Wrong. Have been digging around for hours and found no answer.
Anyone?
If the library you're checking for supplies a .pc file for use with pkg-config, then you're much better off using PKG_CHECK_MODULES to get the correct flags. libpng does:
(in configure.ac)
PKG_CHECK_MODULES([libpng], [libpng12])
This gives you access to the variables $(libpng_CFLAGS) and $(libpng_LIBS) which you will want to add to Makefile.am (probably in AM_CFLAGS/AM_CXXFLAGS and LDADD, or target-specific versions thereof).
It will also cause configure to fail with an error if libpng12.pc isn't found. If you want configure to continue, you'll need to supply the third and fourth arguments to PKG_CHECK_MODULES, which are ACTION-IF-FOUND and ACTION-IF-NOT-FOUND:
(in configure.ac)
PKG_CHECK_MODULES([libpng], [libpng12], [HAVE_LIBPNG=1], [HAVE_LIBPNG=0])
Now, if you need an automake conditional, you can do something like:
(in configure.ac)
AM_CONDITIONAL([USE_LIBPNG], [test "$HAVE_LIBPNG" -eq 1])
If you also need the preprocessor definition, you could use AC_DEFINE like so:
(in configure.ac)
AS_IF([test "$USE_LIBPNG" -eq 1], [AC_DEFINE([USE_LIBPNG], [1], [Define if using libpng.])])
Possibly nicer is to set the definition in Makefile.am:
(in Makefile.am)
AM_CPPFLAGS =
if USE_LIBPNG
AM_CPPFLAGS += -DUSE_LIBPNG
endif
This will clutter your command line, though, whereas AC_DEFINE can put the definition in a header if you use AC_CONFIG_HEADERS. I guess this doesn't really matter if you use AM_SILENT_RULES([yes]) or don't care about your command line being neat (and let's be honest, automake generates some pretty gnarly command lines anyway).
A note on good autoconf style
It is considered poor form to build optional support based on whether or not a check succeeded (see this gentoo doc for details). Here's how I'd code optional support for libpng:
(in configure.ac)
# This is because the first PKG_CHECK_MODULES call is inside a conditional.
PKG_PROG_PKG_CONFIG
AC_ARG_WITH([libpng],
[AS_HELP_STRING([--with-libpng],
[support handling png files #<:#default=check#:>#])],
[],
[with_libpng=check])
AS_CASE(["$with_libpng"],
[yes], [PKG_CHECK_MODULES([libpng], [libpng12], [HAVE_LIBPNG=1])],
[no], [],
[PKG_CHECK_MODULES([libpng], [libpng12], [HAVE_LIBPNG=1], [HAVE_LIBPNG=0])])
AM_CONDITIONAL([USE_LIBPNG], [test "$with_libpng" != no -a "$HAVE_LIBPNG" -eq 1])
(in Makefile.am)
if USE_LIBPNG
AM_CPPFLAGS += -DUSE_LIBPNG
AM_CFLAGS += $(libpng_CFLAGS)
LDADD += $(libpng_LIBS)
libdev_la_SOURCES += png.c
endif
If your library doesn't have a .pc file
For completeness, here's how I'd check for a library that didn't have a .pc file. I'll skip over the details of following good autoconf style. AC_CHECK_LIB sets a cache variable, so you can test that instead of replacing the ACTION-IF-FOUND of AC_CHECK_LIB:
(in configure.ac)
AC_CHECK_LIB([png], [png_create_write_struct_2])
# Then test:
AS_IF([test "$ac_cv_lib_png_png_create_write_struct_2" = yes], [HAVE_LIBPNG=1], [HAVE_LIBPNG=0])
# Or set conditional:
AM_CONDITIONAL([USE_LIBPNG], [test "$ac_cv_lib_png_png_create_write_struct_2" = yes])
IMHO, you should only do it this way if you have no other option.
I will disagree mildly with Jack on his recommendation to use PKG_CHECK_MODULES. It is probably best to avoid using that. But I will agree with Jack on avoiding assigning to LIBS in the 3rd argument to AC_CHECK_LIB. Life is easier if you let AC_CHECK_LIB use the default settings.
Although AC_CHECK_LIB does not define a shell variable indicating whether or not the library was found, you can do this in configure.ac:
AM_CONDITIONAL([USE_LIBPNG],[grep HAVE_LIBPNG confdefs.h > /dev/null])
Arguably, this is relying on internal autoconf details, but in practice will work reliably.
Thanks for the replies.
Jack: I'm trying for maximum portability, so can't assume the libraries were installed as part of a package (they're not on my own box!), which means the no-other-option solution you suggested is what I already tried-- setting a shell variable manually-- but also manually performs the extra steps that would have been done by AC_CHECK_LIB: prepending the library to LIBS and defining HAVE_LIBxxx.
There was a catch though: autoheader complains about the bare AC_DEFINE:
autoheader: warning: missing template: HAVE_LIBPNG
autoheader: Use AC_DEFINE([HAVE_LIBPNG], [], [Description])
I'd be nice if autoheader worked in the future, so I had to change AC_DEFINE to the full monty:
AC_CHECK_LIB([png], [png_create_write_struct_2],
[HAS_LIBPNG=1
LIBS="-lpng $LIBS"
AC_DEFINE([HAVE_LIBPNG], 1, [Define to 1 if you have the `png' library (-lpng)])])
This works, but I don't much like having to duplicate the default behavior of AC_CHECK_LIB.
William: Yes I could grep for the symbol definition in confdefs.h, that also works.
Both solutions have their pros and cons (what doesn't?). Not sure which way I'll go, but it's nice to have options.
Thanks again.
In every platform there are various versions of a given library: multi-threaded, debug, dynamic, etc..
Correct me if I am wrong here, but in Linux an object can link to any version of a library just fine, regardless of how its compiled. For example, there is no need to use any special flags at compile time to specify whether the link will eventually be to a dynamic or a static version of the run-time libraries (clarification: I am not talking about creating dynamic/static libraries, I am talking about linking to them - so -fPIC doesn't apply). Same goes for debug or optimized version of libraries.
Why in MSVC (Windows in general with other compilers. true?) I need to recompile the code every time in order to link to different versions of libraries? I am talking the /MD, /MT, /MTd, /MDd, etc flags. Is the code actually using different system headers each time. If so, why?
I would really appreciate any pointers to solid documentation that discusses these library matters in Windows for a C/C++ programmer..
thanks!
The compiler setting does very little other than simple change some macro definitions. Its microsoft's c-runtime header files that change their behaviour based on the runtime selected.
First, the header files use a # pragma directive to embed in the object file a directive specifying which .lib file to include, choosing one of: msvcrt.lib, msvcrtd.lib, libcmt.lib and mibcmtd.lib
The directives look like this
#ifdef <release dll runtime>
#pragma comment(lib,"msvcrt.lib")
#endif
Next, it also modifies a macro definition used on all c-rt functions that adds the __declspec(dllimport) directive if a dll runtime was selected. the effect of this directive is to change the imported symbol from, say, '_strcmp' to '__imp__strcmp'.
The dll import libraries (msvcrt.lib and msvcrtd.lib) export their symbols (to the linker) as __imp_<function name>, which means that, in the Visual C++ world, once you have compiled code to link against the dll runtimes you cannot change your mind - they will NOT link against a static runtime.
Of course, the reverse is not the case - dll import libraries actually export their public symbols both ways: with and without the __imp_ prefix.
Which means that code built against a static runtime CAN be later co-erced into linking with the dll or static runtimes.
If you are building a static library for other consumers, you should ensure that your compiler settings include:
One of the static library settings, so that consumers of your .lib can choose themselves which c-runtime to use, and
Set the 'Omit Default Library Name' (/Zl)flag. This tells the compiler to ignore the #pragma comment(lib,... directives, so the obj files and resulting lib does NOT have any kind of implicit runtime dependency. If you don't do this, users of your lib who choose a different runtime setting will see confusing messages about duplicate symbols in libc.lib and msvcrt.lib which they will have to bypass by using the ignore default libraries flag.
These using these compiler options have two effects. The automatically #define a macro that may be used by header files (and your own code) to do different things. This effects only a small part of the C runtime, and you can check the headers to see if it's happening in your case.
The other thing is that the C++ compiler embeds a comment in your object file that tells the linker to automatically include a particular flavor of the MSVC runtime, whether you specify that library at link time or not.
This is convenient for small programs, where you simply type at a command prompt cl myprogram.cpp to compile and link, producing myprogram.exe.
You can defeat automatic linking of the commented-in flavor of the c-runtime by passing /nodefaultlib to the linker. And then specify a different flavor of the c-runtime instead. This will work if you are careful not to depend on the #defines for _MT and
_DLL (keep in mind that the standard C headers might be looking at these also).
I don't recommend this, but if you have a reason to need to do this, it can be made to work in most cases.
If you want to know what parts of the C header files behave differently, you should just search for _MT and _DLL in the headers and see.
All of the options use the same header files, however they all imply different #define which affect the header files. So they need to be recompiled.
The switches also link to the appropriate library, but the recompile is not because of the linking.
See here for a list of what is defined when you use each.