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.
Related
I am attempting to build a project that comes with an automake/autoconf build system. This is a well-used project, so I'm skeptical about a problem with the configure scripts, makefiles, or code as I received them. It is likely some kind of environment, path, flag, etc problem - something on my end with simply running the right commands with the right parameters.
The configuration step seems to complete in a satisfactory way. When I run make, I'm shown a set of errors primarily of these types:
error: ‘TRUE’ undeclared here (not in a function)
error: ‘struct work’ has no member named ‘version’
error: expected ‘)’ before ‘PRIu64’
Let's focus on the last one, which I have spent time researching - and I suspect all the errors are related to missing definitions. Apparently the print-friendly extended definitions from the C standard library header file inttypes.h is not being found. However, in the configure step everything is claimed to be in order:
configure:4930: checking for inttypes.h
configure:4930: /usr/bin/x86_64-linux-gnu-gcc -c -g -O2 conftest.c >&5
configure:4930: $? = 0
configure:4930: result: yes
All the INTTYPES flags are set correctly if I look in confdefs.h, config.h, config.log Output Variables, etc:
HAVE_INTTYPES_H='1'
#define HAVE_INTTYPES_H 1
The problem is the same whether doing a native build, or cross-compiling (for arm-linux-gnueabihf, aka armhf).
The source .c file in question does have config.h included as you'd expect, which by my understanding via the m4 macros mechanic should be adding an
#include <inttypes.h>
line. Yes, as you may be inclined to ask, if I enter this line myself into the .c file it appears to work and the PRIu64 errors go away.
I'm left with wondering how to debug this type of problem - essentially, everything I am aware of tells me I've done the configure properly, but I'm left with a bogus make process. Aside from trying every ./configure tweak and trick I can find, I've started looking at the auto-generated Makefile.in itself, but nothing so far. Also looking into how I can get the C pre-processor to tell me which header files it's actually inserting.
EDIT: I've confirmed that the -DHAVE_CONFIG_H mechanic looks good through configure, config.log, Makefile, etc.
autoconf does not automatically produce #include directives. You need to do that on your own based on the HAVE_* macros. So you'll have to add something like this:
#ifdef HAVE_INTTYPES_H
# include <inttypes.h>
#endif
If these lines show up in confdefs.h, a temporary header file used by configure scripts, this does excuse your application from performing these #includes. If configure writes them to confdefs.h, this is solely for the benefit of other configure tests, and not for application use.
First, run make -n for the target that failed. This is probably some .o file; you may need some tweaking to get its path correctly.
Now you have the command used to compile your file. If you don't find the problem by meditating on this command, try to run it, adding the -E to force preprocessor output text instead of invoking the compiler.
Note that now the .o file will be text, and you must rebuild it without -E later.
You may find some preprocessor flags useful to get more details: -dM or -dD, or others.
Pretty much what the title says. I have been trying to build RabbitMQ under Windows using MinGW with no success. Judging by the amount of people I see asking questions about how to use it, I suspect I am making a silly mistake, but I don't know what it is. I'm on Win7-64 and I'm extracting the repo, creating a build directory in it, and running
cmake -G "MinGW Makefiles" ..
which seems to work, and then
cmake --build .
which throws a bunch of function re declaration errors. Does anybody know what I'm botching here?
Just for good measure, a small sampling of the errors:
Linking C shared library librabbitmq.1.dll
CMakeFiles\rabbitmq.dir/objects.a(amqp_api.c.obj):amqp_api.c:(.rdata+0x3c): mult
iple definition of `amqp_empty_array'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x0):
first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_api.c.obj):amqp_api.c:(.rdata+0x44): mult
iple definition of `amqp_empty_table'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x8):
first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_api.c.obj):amqp_api.c:(.rdata+0x4c): mult
iple definition of `amqp_empty_bytes'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x10)
: first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_connection.c.obj):amqp_connection.c:(.bss
+0x0): multiple definition of `amqp_empty_array'
CMakeFiles\rabbitmq.dir/objects.a(amqp_framing.c.obj):amqp_framing.c:(.bss+0x0):
first defined here
CMakeFiles\rabbitmq.dir/objects.a(amqp_connection.c.obj):amqp_connection.c:(.bss
+0x8): multiple definition of `amqp_empty_table'
CMakeFiles\rlibrabbitmq\CMakeFiles\rabbitmq.dir\build.make:271: recipe for targe
t 'librabbitmq/librabbitmq.1.dll' failed
EDIT:
After some time, I have determined that the problem is that the pre-processor directives have some errors in the way they are written. I'm not going to close this for now, and if I ever get the time to fix the whole thing, I will come back here and leave an answer with a solution.
I've been analyzing macros defined in amqp.h file and I've added the extern modifier to the AMQP_PUBLIC_VARIABLE macro when build a non static library.
78 #elif defined(_WIN32) && defined(__MINGW32__)
79 # if defined(AMQP_BUILD) && !defined(AMQP_STATIC)
80 # define AMQP_PUBLIC_FUNCTION __declspec(dllexport)
81 # define AMQP_PUBLIC_VARIABLE __declspec(dllexport) extern
Another thing was, that I've had to modify the WINVER macro on file '/MinGW/include/windef.h' inside MinGW environment to fit with new windows versions.
11 #ifndef WINVER
12 #define WINVER 0x0501
After that, I've built the librabbitmq.1.dll library without problems using cmake -G "MinGW Makefiles" .. && cmake --build . commands
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...
I use to go through C code having lot of #ifdef, #if and #endif directive which keep some portion active and some portion inactive depending on some variables are defined or not. I searched for something that can process them to generate final C code. But the preprocessing also does the same for #include and #define. But I want to keep them.
So, is there any thing to preprocess these files or project with some filtering?
There are a series of programs that can do that:
unifdef - the oldest
sunifdef (Son of Unifdef)
coan (Son of sunifdef)
I've used sunifdef extensively on some very contorted code and have never found it to make a mistake. I'm ready to start using coan now, though it will still be under scrutiny for a while. Version 4.2.2 was released today, 2010-12-20.
See also: SO 525283
I assume you're using gcc.
If you mean all #includes, I think you need to remove them, expand the resulting file with gcc -E then add the #includess back.
If you mean only the standard headers, the option -nostdinc may help you do what you want
user#host:~/test/tmp$ cat 4437465.c
#include <stdio.h>
#ifndef OUTPUT_TYPE
#define OUTPUT_TYPE 1
#endif
int main(void) {
#if OUTPUT_TYPE == 1
printf("output type 1\n");
#elif OUTPUT_TYPE == 2
printf("output type 2\n");
#else
printf("default output type\n");
#endif
return 0;
}
user#host:~/test/tmp$ gcc -DOUTPUT_TYPE=2 -nostdinc -E 4437465.c
# 1 "4437465.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "4437465.c"
4437465.c:1:19: error: no include path in which to search for stdio.h
int main(void) {
printf("output type 2\n");
return 0;
}
what you want might be actually a bad idea, as there might be definitions coming from included files, describing your architecture, for example... But any modern IDE can visualize the #if preprocessor directives.
We used a custom parser to achieve what you intend to do. Lex & YACC
would be a good start for such tool.
On a side note, it was a really painful way to manage different versions of binaries in a large code base. If it's possible, try to isolate your optionnal code parts in different libraries that can or cannot be included in your final deliverable as a dynamic or static library.
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.