I'm trying to use the BFD library, and so I've installed package binutils-dev and have included:
#include <bfd.h>
and am calling bfd_openr and bfd_close and so on from my code.
Recently I have upgraded packages and now I get an error from here:
bfd.h:
/* PR 14072: Ensure that config.h is included first. */
#if !defined PACKAGE && !defined PACKAGE_VERSION
#error config.h must be included before this header
#endif
...that I should include config.h - but I am not using autoconf.
Am I including the wrong header file? How are you supposed to use binutils-dev?
Here is a demo program:
#include <stdio.h>
#include <bfd.h>
int main()
{
bfd_init();
bfd* file = bfd_openr("a.out", 0);
if (!file)
return -1;
if (bfd_check_format(file, bfd_object))
printf("object file\n");
else
printf("not object file\n");
bfd_close(file);
return 0;
}
try to compile and run as follows:
$ sudo apt-get install binutils-dev
$ gcc test.c
In file included from test.c:3:0:
/usr/include/bfd.h:37:2: error: #error config.h must be included before this header
Well, the most correct way of using the header is to use autotools in your package as well. Some people are simply stubborn and I don't think you can do much about it.
An alternative is to work-around the check, by defining the macros it is using:
#define PACKAGE 1
#define PACKAGE_VERSION 1
Of course, if you are already defining those, you may as well set them to some reasonable values like:
#define PACKAGE "your-program-name"
#define PACKAGE_VERSION "1.2.3"
and use them for your program. You'll usually going to use something like that anyway at some point to keep the versions consistent.
This should be enough if you're using a standards-compliant compiler because then the __STDC__ macro will be declared and everything will go on just fine. Well, as long as the headers you're using won't require more autoconf-generated defines.
For example, if you wanted to use plugin-api.h, you'd actually have to handle checking for stdint.h and inttypes.h...
Related
I have been putting together a m68k cross compile "environment/toolchain" of sorts for some upcoming projects I have planned, and I'm having an issue when using it on macOS (my native environment) specifically.
If I follow my own instructions to install on Linux (https://github.com/tomstorey/m68k_bare_metal/blob/master/INSTALL-Debian-Ubuntu.md), then in my code I am able to use types such as uint8_t etc through #include <stdint.h>.
But if I install on macOS and attempt to do the same thing I am greeted with this error:
In file included from main.c:1:
/Users/tstorey/m68k/m68k-unknown-elf/lib/gcc/m68k-unknown-elf/9.3.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
9 | # include_next <stdint.h>
| ^~~~~~~~~~
compilation terminated.
make: *** [main.o] Error 1
I've done a little searching around, but I'm not having much luck finding an answer, perhaps because I don't really know what to search for other than "stdint.h not found".
One topic I did find suggested that include_next shouldnt really be used, but that same person wouldnt recommended modifying the original stdint.h file to work around it. Presumably since in that case it is including <stdint.h> then this file should be located somewhere "system wise", and gcc should know where to look to find it? But presumably that location doesnt exist.
In the same directory where the the stdint.h file I am trying to include is located there is a stdint-gcc.h file which, if I include this in my code, it will compile fine, no worries.
The original stdint.h file does seem to attempt to include this file, but only if __STDC_HOSTED__ is not defined:
$ cat stdint.h
#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
# undef __STDC_LIMIT_MACROS
# define __STDC_LIMIT_MACROS
# undef __STDC_CONSTANT_MACROS
# define __STDC_CONSTANT_MACROS
# endif
# include_next <stdint.h>
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif
Sorry if this post is a bit wofty, but I am not experienced enough with gcc etc to really be able to work this out and I'm still learning a lot about setting all of this up, so I'm wondering if anyone knows what I have missed.
Thanks
When your particular version of gcc has been built, it was apparently not built for a hosted environment (i.e. full availability of a standard C library, for example newlib). When this is the case, you cannot expect standard library support and are on your own.
You probably want to re-build gcc with newlib support.
I'm fairly new to programming in C. My problem is that I have two implementations of a function and I want to be able to switch between them easily.
Right now I define the two implementations of the function as function_implementation1 and function_implementation1 in the files "funtion_implementation1.h" and "funtion_implementation2.h" respectively. To switch between them I have the following file:
#define IMPLEMENTATION1
#ifdef IMPLEMENTATION_1
#include "funtion_implementation1.h"
#define myFunction function_implementation1
#endif
#ifdef IMPLEMENTATION_2
#include "funtion_implementation2.h"
#define myFunction function_implementation2
#endif
In order to switch from one implementation to the other I just have to change the first line. This approach works, and I was satisfied with it for a while, but now it is bugging me that I have to open this file so often. I have a parameters.h file where I define all my parameters and I would rather choose which implementation to use in that file. Sadly, moving the first line to that file does not work. If I do that myFunction is not defined.
What is the best way to do this?
you should include your parameters file where you use alias, macros, etc:
#include "Parameters.h"
also, all your headers files should start with:
#ifndef __FILE_H__
#define __FILE_H__
// definitions go there
#endif
This prevents nested include of header files
Use preprocessor options, specifically the -D option. If you wanted to use IMPLEMENTATION1, when you are compiling that file on the command line (or in IDE), add -D IMPLEMENTATION1. This defines that macro. Same works for any macro
I am working on a large project using C language, which has a lot of preprocessor macros: #ifdef/#if. The macros are defined in makefile.
In order to get the clean code, I modified the makefile to use "gcc -E". But the gcc preprocessor would expand the included header file as well, which I do not expect.
Is there any method to get rid of the #ifdef/#if without expand the included header files? I searched GCC options but not find an answer yet.
An example:
#include "a.h"
#ifdef ABC
func()
#else
func(a)
#endif
{
...
}
In makefile, this source is compiled with -DABC, I am looking for a method to change the file to:
#include "a.h"
func()
{
...
}
If you only want to remove preprocessor conditionals from your code you can use unifdef :
unifdef -DFOO header.h
How does one prevent an inclusion cycle in C? ie. You shouldn't have a.h #include "b.h", which #include's "c.h" which #include's "a.h". I'm looking for a way of preventing this from happening using some sort of C directive.
I had originally thought this would've prevented this from happening:
Contents of a.h:
#ifndef __A_H
#define __A_H
#include "b.h"
#endif // __A_H
Contents of b.h:
#ifndef __B_H
#define __B_H
#include "c.h"
#endif // __B_H
Contents of c.h:
#ifndef __C_H
#define __C_H
#include "a.h"
#endif // __C_H
But it doesn't seem to work.
It does work allright: the files are repeatedly included, but the sections protected by #ifdndef/#define/#endif are not repeated, and that breaks the cycle.
Use your compiler to produce the preprocessed output and look at it for yourself. With GNU CC, you need to use "-E" option on the .c[pp] file, like this:
gcc -E $(CFLAGS) -o foo.i foo.cpp
That should work. It's written correctly in your example and compiles fine for me. Did you mistype something in your actual code, or is it really some other problem you're seeing?
You shouldn't start things out with __, though, as that's reserved for the compiler and/or system libraries. Try some other names for your guards.
Macros with leading underscores are reserved for the preprocessor/compiler.
Try changing __*_H to something more standard.
I use HAVE__*_H.
ya in addition to the above things if you are working on turbo c and you are doing a project with these source files then do not attach the header files which are #included in the source files.And even then if it is not working then try it from command prompt because some compiler options give these errors again and again.so here if the header files contents are between the #ifndef and #endif then there will be no problem even you include both the files. So try removing the header files from the project keeping them in the same directory.bcos u didnt specified environment i specified turbo C because i faced this situation once on turbo C with the header files #included in source file and attached to the project files list then there will be "multiple declaration problem".also after compiling (even with errors) go to external command line and go to directory where that file is stored and try with the filename.exe directly.ok
This works.
Just to be sure, I actually compiled a test.c that included a.h with your 3 header files.
I verified this works for several versions of MSVC, Digital Mars and GCC.
I use a parser generator here, that unfortunately insists on putting a
#include <some/file.h>
at the top of every generated source file. The header has since long been renamed. While it is no problem forcing the compiler (gcc) to use the new header with -include new/header.h, removing the above directive from every generated file complicates the build-process.
Is there a way to tell gcc to simply ignore some/file.h?
No. You can post-process your generated file - I say: NO!!!
Or you can just add '.' to your system include directories (or whatever your local include path is - make sure it's also a <> system include path).
Then make a 'some' directory and stick your own permanent 'file.h' in there that has 1 line for #include and get rid of your -include.
I'm guess there's some reason that might not work - cause it seems like the more straight forward and understandable thing to do before using -include. Especially since you can comment the pass-through file to explain what's going on.
Replace some/file.h with an empty file.
Why not make a symlink from some/file.h to new/header.h, and remove the -include directive?
Try using preprocessor directives like #if and #ifdef and gcc -DSYMBOL=value command line flag.
In example, if you compile using gcc -DREQUIRE_STDC=1 -o myfile.o myfile.c, and your .c file contains:
#if defined(REQUIRE_STDC) && defined(__STDC__)
#include "some/file.h"
#else
#include "another/file.h"
#endif /* defined(REQUIRE_STDC) && defined(__STDC__) */
It will compile using "some/file.h" if have both STDC and REQUIRE_STDC symbols defined. Also your header may include the proper directive to avoid multiple inclusions of the same file:
#ifndef MY_HEADER_FILE
#define MY_HEADER_FILE 1
/* your C declarations here */
#endif /* MY_HEADER_FILE */
Also, you could the gcc preprocessor manual.
#include <some/file.h>
may start as something like
#ifndef _FILE_H_
#define _FILE_H_
If so, just add #define _FILE_H_ before the #include command and it should ignore it.
I'm not sure whether this is the best solution, though.