How do I make gcc as verbose as possible? - c

I am currently using the following flags for my gcc compiler:
gcc -std=c99 -pedantic -Wall D_DEFAULT_SOURCE -g -c filename.c
But how can I make the output as verbose as possible? The error messages I am getting in C are not as nice as I am used to from more high level languages and I want to get as much information out of the gcc compiler as possible.


This is a summary of all comments I've received on this post:
These flags are the best you can use to make your compiler as verbose as
possible:
-pedantic -Wall -Wextra -Wwrite-strings -g3
Other flags such as -v and the entire -d* family will make the compilation process more verbose but won't enhance the error messages you are getting.
Check your current version with gcc --version. To get the newest gcc Version (i.e. gcc 12.2 since August 19, 2022) you might have to clone the gcc repository and build it yourself based on the distro (check via lsb_release -d) you are using.
Check this stackoverflow question out to install gcc 12.2 on Ubuntu.
Alternatively you could also directly get gcc-11 from apt without upgrading to the latest bleeding edge ubuntu (don't forget to use gcc-11 instead of gcc afterwards to compile).

Related

.dSYM folder for debugging

I just set-up GNU gcc on my Mac through some re-organization of my path and builds so it's not an alias for clang anymore. Running gcc -g, I expect debugging symbols to be self-contained within the executable, but they are still generating the .dSYM. How can I get the behavior I expect instead of the .dSYM folder, which I believe comes from Xcode command line tools?
I am specifically running:
gcc -O3 -g3 -Wall -Wextra -fanalyzer -march=native -mtune=native -mrdrnd
but this behavior even occurs with basic gcc -g hello.c -o hello_world program.

ssize_t undefined in a dpdk header

I have an installation of DPDK and I'm trying to compile code with it. This worked on my WSL machine, however on the test server, with the same install of dpdk, I'm getting the error:
/usr/local/include/rte_mempool.h: error: unknown type name 'ssize_t'
I've noticed this header does not include /sys/types.h, but it also doesn't include that on the machine that this works on. I don't know where it's supposed to come from, but it's coming from somewhere.
How do I get these headers to be aware of ssize_t?
As noted in a comment:
The compiler options include -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h, and a whole bunch of -l options (dpdk's make structure adds these in). This prompted me to run gcc --version and the working one is Ubuntu gcc 9.3.0 and the broken one is gcc 5.4.0. Seems like it might be an incompatibility between dpdk and the gcc installed.

As mentioned in the comments by #JonathanLeffier, the root cause of the issue is including sys/types.h when gcc option --std=c99 is passed. The easiest fix without modifying the DPDK or sample code is to include the path to types.h as part of cflags.
If the native build is for x86_64 target, follow these steps:
execute find /usr/include/ -name types.h to identify the right file for local build (this is because the current cflags has -march=native)
modify the CFLAGS from -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h to -std=c99 -O3 -march=native -I/usr/local/include -include rte_config.h --include=/usr/include/[target-machine]/sys/types.h
Note: In my humble suggestion please use pkg-config for populating the right CFLAGS and LDFLAGS for both shared and static binary.

How to emit debug information using llvm ir in Clang?

Using clang or clang++ the command of
clang -S -emit-llvm ./source.c
will create a llvm ir document. However debugging information is missing. So when you test and compile things you lose debugging information.
How does one can make clang emit human readable llvm ir document with debug information ?

The standard option to add debug info is -g. So, running clang -g -S -emit-llvm source.c will emit necessary information

Why Does GCC Throw Errors About Unspecified Options?

When I run the following command from a makefile on 64-bit Red Hat Enterprise Linux 5.0 using GCC 4.2.3:
gcc -c -ansi -pedantic -O0 -fPIC -I. -I.. -Iheader_files/include "source_file.c"
I get the following error:
cc1: error: unrecognized command line option "-lang-c"
Superficially, the problem is that "-lang-c" is no longer a valid option on newer versions of GCC. However, the deeper question is: Why does GCC receive a "-lang-c" option that wasn't in the original command?
Additional background:
The current installation doesn't have any GCC "specs" files that I can find
Running "gcc -dumpspecs" produces a long list of defaults, but "-lang-c" isn't among them.
"-lang-c" does not appear to be in any environment variables that I know of that influence GCC.
Any help would be appreciated.
Regards,
Mark Biesiada

Make sure that your gcc driver program is the same version as your installed GCC.
Add the -v option to your compile command to check the versions and where the options are coming from.

sscanf + c99 not working on some platforms?

When I compile a simple Hello World! program that uses the sscanf function on my local Debian lenny x64, it works. But when I upload the same program to the server running CentOS x86, it will not work. If I do not use sscanf, then the program works on both computers.
gcc -std=c99 -O2 -pipe -m32
If I compile it with sscanf but without -std=c99, then it works on both computers.
gcc -O2 -pipe -m32
What is the problem with sscanf and c99 on CentOS x86 ? I thought that compiling with the -m32 flag would work on all Linuxes ? (I have limited access to the CentOS server, so I do not have access to error messages.)

Probably the CentOS box is using an old version of glibc. Since the nonstandard GNU extensions to their scanf implementation ended up making glibc conflict with c99, they added a nasty hack of redirecting *scanf to __isoc99_*scanf when -std=c99 is in use; if your copy of glibc is missing the __isoc99_sscanf symbol, the program will then fail to run.
Static linking, or linking to a different libc without ugly backwardsness-compatibility hacks, would solve the problem.

Are you uploading the binary or the source and then recompiling? If you are uploading the binary, you are probably running into a library compatibility issue between Debian and CentOS.
If that is the case, upload the source only and recompile on CentOS.

If you do not have permission to compile # CentOS, then try compiling a static binary. You can use dietlibc which makes smaller binaries than glibc or try EGLIBC which is the default C library that Debian will use starting Debian "squeeze".

I came up with the similar problem, it works # Ubuntu 64-bit, but the compile fails # CenseOS 64-bit (REHL5 desktop):
the error message is:
undefined reference to `__isoc99_sscanf#GLIBC_2.7'
when i copied the executable file compiled #Ubuntu to REHL5, and run it another error appeared:
elf file os abi invalid
it is compiled without flag -std=c99, i'm a newbie at C, and looking forword some workarounds, ex. add some flag.
Makefile:
CC=gcc
CCFLAGS= -Wall -O2 -DLINUX -I../include
demos:linuxdemo.c
$(CC) $(CCFLAGS) -o demoA linuxdemo.c -L../lib -lsense4 -lusb
$(CC) $(CCFLAGS) -o demoSO linuxdemo.c -lusb -lsense4
clean:
rm -f demoA
rm -f demoSO

You need to update your glibc to 2.7
download the rpm package from here:
http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/8/Everything/x86_64/os/Packages/
needs:
libc-common-2.7-2.x86_64.rpm
glibc-headers-2.7-2.x86_64.rpm
glibc-devel-2.7-2.x86_64.rpm
glibc-2.7-2.x86_64.rpm
command:
rpm -Uvh --aid --nodeps glibc-common-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.7-2.x86_64.rpm

Resources