I am compiling some C/C++ files using gcc.
I noticed today a bug that caused my app to crash. It was caused by the fact that my function didn't return any value (see below). Do you know if there is some flag in gcc enforcing these kind of checking or why the compiler is not warning me about this?
I am compiling C files into object files with a basic -g -D_GNU_SOURCE -o outObjectFile -c myFile.c option.
//.c file
int
myFunc(){
...do something
..without return statement
}
//.h file
extern int myFun();
When using GCC, always compile with:
-std=c99 -pedantic -Wall -Wextra -Wwrite-strings for C
-ansi -pedantic -Wall -Wextra -Weffc++ for C++
Related
I am trying to compile FormCalc 9.9 on a MacOS 10.10.5.
Compilation consists in running a bash script on terminal. I redirect both stdout and sterr to a log file, but this is all the output I get:
$ ./compile
Compiling for system type MacOSX-x86-64
cp -p ./bin/MacOSX-x86-64/* MacOSX-x86-64/
gcc -O3 -fomit-frame-pointer -ffast-math -Wall -Wextra -m64 -o MacOSX-x86-64/ToForm ./FormCalc/ToForm.c
./FormCalc/ToForm.c:72:9: warning: declaration does not declare anything [-Wmissing-declarations]
__attribute__ ((fallthrough));
^
>
1 warning generated.
strip MacOSX-x86-64/ToForm
gcc -O3 -fomit-frame-pointer -ffast-math -Wall -Wextra -m64 -o MacOSX-x86-64/ToFortran ./FormCalc/ToFortran.c
strip MacOSX-x86-64/ToFortran
gcc -O3 -fomit-frame-pointer -ffast-math -Wall -Wextra -m64 -o MacOSX-x86-64/ToC ./FormCalc/ToC.c
strip MacOSX-x86-64/ToC
gcc -O3 -fomit-frame-pointer -ffast-math -Wall -Wextra -m64 -o MacOSX-x86-64/reorder ./tools/reorder.c
strip MacOSX-x86-64/reorder
looking for gcc... /usr/bin/clang
looking for g++... /usr/bin/clang++
looking for fortran... /usr/local/bin/gfortran
extracting the Fortran libraries... ok
does gfortran append underscores... error linking Fortran and C
How can I get more information about the linking error?
I've tested this on GCC 4.8.3, 4.9.2 and trunk 20141210. When using -Werror=write-strings, it correctly enables the warning, but doesn't turn it into an error. The command line I'm using is:
g++ -std=c99 -x c -Werror=write-strings -O2 -Wall -pedantic main.cpp
warning: initialization discards 'const' qualifier from pointer target type
char *s = "test";
However, it turns it into an error in C++ mode:
g++ -Werror=write-strings -O2 -Wall -pedantic -pthread main.cpp
main.cpp:8:15: error: deprecated conversion from string constant to 'char*'
[-Werror=write-strings]
char *s = "test";
Is there something I'm missing or is this just a missing feature?
I've seen the deleted answer, but bear with me…it was actually correct (at least, under my testing). I think what you've found is interesting, and close to being a bug.
As far as my testing goes (GCC 4.9.1 built on Mac OS X 10.9.4 Mavericks, running on Mac OS X 10.10.2 Yosemite), it appears that the -Werror=write-strings does not make the warning into an error (which I regard as being probably a bug, though you may find that the GCC team has a different view on it). It only becomes an error when -Werror is in effect.
Here's what I ran:
$ cat x.c
#include <stdio.h>
int main(void)
{
char *test = "data";
printf("%s\n", test);
return 0;
}
$ gcc -O3 -g -std=c11 -c x.c
$ gcc -O3 -g -std=c11 -c x.c -Wwrite-strings
x.c: In function ‘main’:
x.c:5:18: warning: initialization discards ‘const’ qualifier from pointer target type
char *test = "data";
^
$ gcc -O3 -g -std=c11 -c x.c -Werror=write-strings
x.c: In function ‘main’:
x.c:5:18: warning: initialization discards ‘const’ qualifier from pointer target type
char *test = "data";
^
$ gcc -O3 -g -std=c11 -c x.c -Werror -Wwrite-strings
x.c: In function ‘main’:
x.c:5:18: error: initialization discards ‘const’ qualifier from pointer target type [-Werror]
char *test = "data";
^
cc1: all warnings being treated as errors
$ gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror=write-strings
x.c: In function ‘main’:
x.c:5:18: warning: initialization discards ‘const’ qualifier from pointer target type
char *test = "data";
^
$ gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror
$ gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror -Wwrite-strings
x.c: In function ‘main’:
x.c:5:18: error: initialization discards ‘const’ qualifier from pointer target type [-Werror]
char *test = "data";
^
cc1: all warnings being treated as errors
$ gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror -Werror=write-strings
x.c: In function ‘main’:
x.c:5:18: error: initialization discards ‘const’ qualifier from pointer target type [-Werror]
char *test = "data";
^
cc1: all warnings being treated as errors
$
For your convenience, and for easier viewing, these are the GCC commands I ran:
gcc -O3 -g -std=c11 -c x.c
gcc -O3 -g -std=c11 -c x.c -Wwrite-strings
gcc -O3 -g -std=c11 -c x.c -Werror=write-strings
gcc -O3 -g -std=c11 -c x.c -Werror -Wwrite-strings
gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror=write-strings
gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror
gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror -Wwrite-strings
gcc -O3 -g -std=c11 -c x.c -Wall -Wextra -Werror -Werror=write-strings
If you can't run with -Werror normally, then you're probably going to have to do trial builds with -Werror -Wwrite-strings which will fail because of other problems, but this will also identify the writable strings problems, which you can fix and check. Then, when you're OK on the -Wwrite-strings errors, you can go back to not including -Werror in the compilation (keeping -Wwrite-strings or even -Werror=write-strings in the command line so that if you make a mistake and/or the putative compiler bug is fixed, then you can have it all working the way you really wanted).
I am attempting to use Mingw-w64's 32-bit compiler (the i686-w64-mingw32 toolchain) to cross-compile the ICU library for Windows. The host is Ubuntu 12.10 64-bit.
The steps I have taken look something like this:
Grab the latest source code archive from here and extract it.
Make two copies of the source/ directory - one for the host and one for the target.
For the host build:
./configure ; make
For the target build:
./configure --host=i686-w64-mingw32 --with-cross-build=<host_source_dir>
...where <host_source_dir> is the directory from the previous step.
When I run make in the target source directory, compilation proceeds without any errors for a few moments and then throws this error:
i686-w64-mingw32-g++ -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -mthreads -o ../../bin/uconv.exe uconv.o uwmsg.o
-L../../lib -licuin50 -L../../lib -licuuc50 -L../../stubdata -licudt50
-lm uconvmsg/uconvmsg.a
uconv.o:uconv.cpp:(.text+0x2f): undefined reference to `_uconvmsg_dat'
What could be causing this error? I backed up a few lines and also noticed this:
pkgdata: i686-w64-mingw32-gcc -O2 -Wall -std=c99 -pedantic -Wshadow
-Wpointer-arith -Wmissing-prototypes -Wwrite-strings -mthreads -shared
-Wl,-Bsymbolic -Wl,--enable-auto-import -Wl,--out-implib=./all.lib -o
../lib/icudt50.dll ./out/tmp/icudt50l_dat.o
Cannot export icudt50_dat: symbol not found
collect2: ld returned 1 exit status
-- return status = 256
Error generating library file. Failed command: i686-w64-mingw32-gcc -O2 -Wall
-std=c99 -pedantic -Wshadow -Wpointer-arith -Wmissing-prototypes
-Wwrite-strings -mthreads -shared -Wl,-Bsymbolic -Wl,--enable-auto-import
-Wl,--out-implib=./all.lib -o ../lib/icudt50.dll ./out/tmp/icudt50l_dat.o
Error generating assembly code for data.
What am I doing wrong?
In order to debug your symbol problem just provide the flag -Wl,--trace-symbol=_uconvmsg_dat to i686-w64-mingw32-g++ like follows:
i686-w64-mingw32-g++ -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -mthreads -o ../../bin/uconv.exe uconv.o uwmsg.o
-L../../lib -licuin50 -L../../lib -licuuc50 -L../../stubdata -licudt50
-lm uconvmsg/uconvmsg.a -Wl,--trace-symbol=_uconvmsg_dat
So it turns out that the problem was indeed with the ICU source code. I'm not sure I understand exactly what the problem is, but thankfully someone else did and wrote three patches.
The first two apply to my question above:
icu4c-50_1_2-crossbuild.patch
icu4c-4_6_1-win32.patch
The third patch is used instead of the second in the list above when building for the x86_64 architecture:
icu4c-4_6_1-win64.patch
There does still seem to be a problem when running make install, but at least the source tree seems to build now.
I am trying to run program from the Learn C Hard Way book
I need to pass the library filename 'build/liblcthw.a' as the last parameter.
For eg :
Doesnt Work on Ubuntu :
gcc -g -O2 -Wall -Wextra -Isrc -rdynamic -DNDEBUG build/liblcthw.a tests/list_tests.c -o tests/list_tests
Works on Ubuntu :
gcc -g -O2 -Wall -Wextra -Isrc -rdynamic -DNDEBUG tests/list_tests.c -o tests/list_tests build/liblcthw.a
How do I handle this in Makefile ? CFLAGS will only add it before the source filename and it doesnt work. How do I force CFALGS to add the library filename at the end of the command ?
CFLAGS are flags for the C compiler. Libraries typically go into a variable called LDLIBS. Set LDLIBS=build/liblcthw.a and see if that works.
The first invocation doesn't succeed because the order of sources and libraries in the command line is wrong. The correct order is source files, then object files, followed by static libraries followed by dynamic libraries.
In a Makefile of a library I am trying to build, there are a few lines specify the options to gcc:
CFLAGS += -I$(CURDIR) -pedantic -std=c89 -O3
CFLAGS += -Wall -Wno-unused-function -Wno-long-long
CFLAGS += $(if $(DEBUG), -O0 -g)
If DEBUG exists, there will be both -O3 and -O0 -g in CFLAGS. But -O0 and -O3 cannot be used at the same time. Will the one specified later supersede the one earlier?
Thanks and regards!
From the manpage:
If you use multiple -O options, with or without level numbers, the
last such option is the one that is effective.