A particular C++ logging library called spdlog that I use in my project has a broken package on CentOS (the platform I'm trying to compile on) where the header file will only compile if SPDLOG_FMT_EXTERNAL is defined before any of its files are included. [And this will not be fixed.]
I am trying to find a way to use autoconf directives to test for the presence of this header file - previously I used a homegrown macro that compiles a program which uses that, but its speed latency is unacceptably slow so I am trying to replace it.
Here is the relevant snippet of my configure.ac:
dnl check for libfmt is done earlier...
AC_CHECK_HEADERS([spdlog/spdlog.h], [have_spdlog="yes"], [have_spdlog="no"])
if test x$have_spdlog = xyes; then
LDFLAGS="$LDFLAGS -lspdlog -lfmt";
else
AC_MSG_ERROR([spdlog is required for logging support but is missing.])
fi
The header file spdlog/spdlog.h exists, but Autoconf deems it as not usable because it won't compile by itself.
AC_CHECK_HEADERS has a parameter I can specify include files required to include that particular header file. I can use that to specify the #define macro before the file is included.
Is there an easier way to just directly specify a macro without creating a new header file?
After some experimenting, I learned that the fourth parameter to AC_CHECK_HEADERS accepts macros as well - anything that can be used in a C/C++ preprocessor works as well, such as #ifdef, #endif and so on. It is not restricted to only #include directives.
AC_CHECK_HEADERS([spdlog/spdlog.h], [have_spdlog="yes"], [have_spdlog="no"], [
#define SPDLOG_FMT_EXTERNAL
])
Related
I'm building NWChem on Cray. libtcmalloc_minimal is already added to an archive file by the cc in my Cray environment. In my configure routine, it explicitly appends a second -ltcmalloc_minimal resulting in a multiple definition and a configure fail. But none of the configure.* files or makefiles (or any files included with NWChem) contain any reference to tcmalloc_minimal.
How is tcmalloc_minimal getting in there?
How can I keep it out?
The autoconf _AC_FC_LIBRARY_LDFLAGS macro (called as part of AC_PROG_FC) and other macros querying library flags and objects retrieves this value from the verbose compiler output (which contains this library on Cray systems). For this reason Cray's patched autoconf contains a change of the above macro to get rid of the flag. I'm currently in the process of figuring out an override to the macro so configure scripts produced by unpatched versions of autoconf also work on Cray systems. I'll post an update once I've figured out something reliably working.
What is the purpose of the features.h header? Why and when can it be used in my code?
Does it define source features supported by the system?
Or does it define some additional things which must be defined depending on other defines?
The features.h header file provides various macro definitions that indicate standard conformance to other header files, i.e. which features (hence the name) should be turned on or off depending on which standard the user wishes to use.
Most C/C++ compilers have command line options to handle standards conformance. Let's take GCC as an example: when you pass the -std=gnu9x option, you ask for the GNU dialect of the C99 standard. The features.h header makes sure that all other headers that include it will turn exactly those features on or off that are needed to support this particular dialect. This is achieved by #define -ing or #undef - ing some "intermediate" macros.
As a bonus, features.h also provides the glibc version information macros as well, and various other bits & bobs.
I have grepped POSIX 7 as explained at: https://unix.stackexchange.com/questions/340285/install-the-latest-posix-man-pages/483198#483198 and there are no hits for features.h, so it must be a glibc extension only.
In glibc 2.28, it is present at include/features.h.
One of the interesting things that it defines are version macros:
#include <stdio.h>
#include <features.h>
int main(void) {
printf("__GLIBC__ %u\n", __GLIBC__);
printf("__GLIBC_MINOR__ %u\n", __GLIBC_MINOR__);
return 0;
}
Ubuntu 16.04, which has glibc 2.23, this outputs:
__GLIBC__ 2
__GLIBC_MINOR__ 23
See also: Check glibc version for a particular gcc compiler
Also, this header seems to get included in most / all glibc headers, which might allow you to check if glibc is being used: How to tell if glibc is used but TODO I couldn't find a documentation for that.
From features.h File Reference
Defines on whether to include algorithm variants.
Less variants reduce executable size and compile time. This file is a GNU parallel extension to the Standard C++ Library.
So this file will include some algorithm listed in the reference page.
In general if you need to use any of the variables or functions defined in a header file, you need to include it in your program. This rule is valid for features.h also. You can see a URL for features.h for your reference below:
http://repo-genesis3.cbi.utsa.edu/crossref/heccer/usr/include/features.h.html
We are using a precompiled header to include library files such as Boost and Windows.
Our precompiled.h is included explicitly at the top of each .cpp file in order to work with the precompiled header commands (/Yc, /Yu, and /Fp). I accepted that as necessary.
Recently, however, I found /FI, which forces an include file at the top of the source file. I tried using it to force-include precompiled.h instead of including it explicitly, and sure enough, it worked.
This would allow us to omit the precompiled header (which is an implementation detail, as far as I am concerned), and only specify the actual dependencies of the file.
Unfortunately, it looks like the only way to validate that we aren't relying on implicit dependencies provided by precompiled.h is to periodically run through a build without /FI"precompiled.h" to see which files have a problem.
This is fairly onerous. Is there a better way?
I need to branch a certain statement in a precompiled-header .h file, based on whether the .h is now being used to create the PCH (i.e., included in a cpp compiled with /Yc), or now included just to use the PCH (i.e., included in a cpp compiled with /Yu).
In other words, I'm looking for something like -
#ifdef NOW_CREATING_THE_PCH
#import yadayada_with_option_a
#else
#import yadayada_with_option_b
#endif
...and can't find anything.
Any ideas would be appreciated!
Thanks,
-Ofek
[Edit:] The reason I need this is that I use Incredibuild, and have started getting this warning. Per the FAQ suggestion, I wish to #import with no_implementation during PCH creation, and with implementation_only during PCH usage.
You can specifically change the configuration (in Visual Studio) of stdafx.cpp (or whatever source file you have that gets compiled with /Yc) to define the symbol NOW_CREATING_THE_PCH, leaving the symbol undefined for the rest of the source files (which get compiled with /Yu).
That's not something you get out-of-the-box, but if you need to do it just for one project (or a few), it's not a problem.
While this is not a direct answer to your question, the simplest way of solving this problem is to use the #import statement with no_implementation in the header file which is used to generate the precompiled header (usually StdAfx.h) and re-#import the header file into the source file that is used to trigger the generation of the pch with the parameter implementation_only. That way the implementation of the wrapper functions are being defined, but only in one place.
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.