ensure config.h is included once
I have a library project that I’m working on porting to using the autotools suite in Linux. I’m quite new to autotools (this week). I’ve learned the basics of its operation. I have a question about how to keep the contents of config.h from being redefined. I’m surprised to find that the generated config.h file doesn’t either, 1) wrap each macro in a #ifndef or, 2) that the entire file isn’t wrapped in the standard #ifndef CONFIG_H . As I’ve alluded, this code is built on Windows and Linux. Thus there are several uses of a macro, _linux (I’m not saying that’s the best name, but it’s in use everywhere) to bring in elements to classes which exist in Linux only. Thus, this will happen header.h
#ifndef HEADER1_H #define HEADER1_H #ifdef HAVE_CONFIG_H #include "config.h" #endif #endif #ifdef HAVE_CONFIG_H #include "config.h" #endif #include "header.h" // oops, preprocessor gets excited because of redefs One simple solution is I do that standard unique wrap in config.h.in after the file is generated. However, I was wondering, is there a better way of handling this? I can’t be the first to encounter this and there might even be a means of handling it in configure.ac but being a complete neophyte in this, I don’t know what to even search for.
2 Answers 2
The way I do this is indeed creating a wrapper file (which I usually call global.h ) that reads like this.
#ifndef MY_PROJECT_GLOBAL_H #define MY_PROJECT_GLOBAL_H #include /* Maybe other global definitions… */ #endif Note that the recommended way to #include the config.h file is via not «config.h» so it works better with VPATH builds.
Then, all the source files in my project #include this global.h header as their very first #include and don’t care about config.h . A header file should never #include config.h since this would lead to bad name conflicts. Actually, if you stick to this guideline, your code should also work without #include guards in the configuration header.
Update regarding OP’s comment
Or: How to use configuration results in headers?
If your headers need to declare different things depending on the results of the configure script, you have a number of options, none of which is perfect.
For internal headers, there is no problem. They simply rely on the macros being #define d without #include ing anything. This works if – as is recommended – all source files #include (maybe indirectly as shown above) config.h before any other header.
If the headers are to be installed publicly, this is not such a great solution. For those of your users that use Autoconf, it wouldn’t be that bad, although even those would have to remember what checks to place in their configure.ac files. For users who don’t use Autoconf, it will be pretty bad. If you only have a few switches (such as Glibc’s fature test macros), it is okay to ask your users to #define them before #include ing your headers but if you need many, this is not a real option. Not to mention that you’ll expose a lot of implementation details to your users that way.
If all you need to do is branch depending on the platform you are building for, you could probe some of the pre-defined macros like __linux or _WIN32 . There is the Boost.Predef library that aims to make these check a little more convenient by providing a higher-level abstraction. The library works with C and C++ alike but, of course, it adds an additional dependency to your project.
Finally, you could make a version of your config.h that uses a macro prefix specific to your project. There is a contribution in the Autoconf macro archive that does exactly that for you. A minimal example could look like this.
AC_PREREQ([2.69]) AC_INIT([example-project], [1.0], [bugs@example.org]) AC_CONFIG_SRCDIR([example.c]) AC_CONFIG_MACRO_DIR([m4]) AC_CONFIG_HEADERS([config.h]) AX_PREFIX_CONFIG_H([public_config.h], [EXAMPLE_PROJECT], [config.h]) AC_PROG_CC AC_OUTPUT
Save this as configure.ac , download ax_prefix_config_h.m4 from the Autoconf macro archive and place it in the sub-directory m4 and then run autoreconf && ./configure . It will create the normal config.h and in addition public_config.h where in the latter file, all macros are prefixed with EXAMPLE_PROJECT_ . The file public_config.h (which also has #include guards by the way) can be installed and #include d in your project’s public header files if need be.
My computer doesn’t recognize the following library: linux/config.h when compiling
I have code written in C and I have included some libraries such as linux/config.h and linux/kernel.h. Whenever I compile the file, it gives me an error saying No such file or directory ? Is there a certain program I should install first ? How can I solve this error ?
No I just downloaded the driver and that is what I got when I compiled the file ? but as you asked I check and all the header files are in directory usr/src/linux-headers-3.2.0-41/include/linux ?? does this help ??
Maybe this quick and dirty solution works: Add «-I/usr/src/linux-headers-3.2.0-41/include/» to your $CFLAGS when running configure, make, etc (if you have no CFLAGS yet, you can simply write «CFLAGS=’-I/usr/src/linux-headers-3.2.0-41/include/’ make»). This should instruct your compiler to look in that folder.
@Zeyad: I think that your compiler simply has no access to that path. You need to inform your compiler where to seek for this files. Instead of #include «linux/config.h» write: #include «usr/src/linux-headers-3.2.0-41/include/linux/config.h» . Does this help?
2 Answers 2
As the link below explains, somewhere in the 2.6.19 kernel, linux/config.h was removed.
#include "usr/src/linux-headers-3.2.0-41/include/linux/config.h" helps, it means that your compiler doesn’t know where to look for include files.
If you are using makefile or command-line compilation then this page will explain what was happening. Othwerise, if you are using some IDE like Eclipse or Code::Blocks, than you need to find project opsions and add include file directries.
Gtk can’t find «»
and I can’t fint this header nowhere so I can’t get those examples to work. What is this about?
Where I can take or with what I can replace this header?
Or I can configure such files/projects differently to get them work as other gtk project works on my comp? Currently I try to compile socket example testsocket.c and during compilation I get error undefined reference to ‘create_child_plug’. I don’t see any reason for this to don’t work except in this header.
But I may be wrong anyway.
2 Answers 2
I think you’re trying to compile a single source file on its own, that wasn’t designed to work on its own. Two reasons.
The first reason: config.h is the default name of the header file output by Autoconf that contains platform-specific defines. That’s why you won’t find it anywhere — it’s generated when you run ./configure on your project and its contents depend on how your system is configured. So it won’t be included with any project, you have to generate it yourself by using Autoconf. Or just comment out the #include and see what definitions are missing, then define them yourself.
Currently I try to compile socket example testsocket.c and during compilation I get error undefined reference to ‘create_child_plug’. I don’t see any reason for this to don’t work except in this header. But I may be wrong anyway.
Actually, that file contains a definition of create_child_plug :
extern guint32 create_child_plug (guint32 xid, gboolean local); So the problem isn’t that create_child_plug isn’t defined. You don’t need a header, it’s defined right there in the source file. extern means that the actual code for this function is in a different source file. In this case, you are getting a link-time (not compile-time) error because the linker can’t find any code for that function. You should look for it in a .c file, not a .h file, and compile that code too.
I suggest you download the whole GTK source code and compile that, and run the test programs from there, instead of picking individual source files off the net.