What is the of the "-pedantic" flag in LOCAL_CFLAGS for Android.mk builds?
And is there any place to find all the possible flags and their meaning?
thanks
I'm not familiar with the Android build systems, but CFLAGS is usually a variable describing flags to pass to the C compiler.
If you use the clang or GCC compiler families, the -pedantic flag enables particularly "picky" warnings about your code. See the option index and the warnings section for GCC.
Related
Does the gcc's option -static affect only one library that follows immediately or does it affect all libraries provided on command line?
g++ -static -lutils1 -lutils2
GGC's -static linkage option prevents linkage with shared libraries. So
all libraries that the linkage requires must be static. The
linker must be able to find a static library to resolve all -lname options that
are passed, as well as static versions of all default libraries that GCC silently
appends to the linkage.
That is the intended use of the -static option, although it is possible to make it more flexible.
GCC's -static option works simply by causing GCC to pass the option -static|-Bstatic to the linker (ld), at
a position in the generated ld commandline that precedes all the libraries in
the linkage.
The linker's -static option has a different meaning from GCC's. From the ld manual:
-Bstatic
-dn
-non_shared
-static
Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are supported.
he different variants of this option are for compatibility with various systems.
You may use this option multiple times on the command line: it affects library searching for -l options which follow it.
(My emphasis)
So the linker's -static|-Bstatic option means: Do not link any shared libraries until further notice. At a later
point in the ld commandline you may cancel the effect of -static|-BStatic with the option -Bdynamic, which
will allow dynamic libraries to be linked again, from that point on, until further notice.
Unlike the linker, GCC has no option that cancels the effect of its -static option. However, GCC allows you to pass abitrary options through to ld, via -Wl,<ld-options>.
So you can in fact cancel GCC's -static option at a later point in the commandline like this:
gcc -static -o prog main.o -lfoo -lbar -Wl,-Bdynamic -lgum ...
This will generate a linkage commandline in which -lfoo and -lbar must be resolved to
static libraries but -lgum and any subsequent library can be resolved to
a shared library or a static library, as usual. Though if you wanted to "turn on/turn off"
dynamic linkage like this at different points in the commandline, it would be more
natural not to use GCC's -static option and instead write the equivalent:
gcc -o prog main.o -Wl,-Bstatic -lfoo -lbar -Wl,-Bdynamic -lgum ...
I would like to prepare GNU toolchain for bare metal ARM to use it with Geany IDE. There are some tutorials like this one: Building the GNU ARM Toolchain for Bare Metal but I do not understand few steps.
First of all, everyone who uses Linux OS implicitly has gcc, binutils and gdb so why to download others? Secondly all tutorials tell me to configure gcc with something like that: *./configure --target=arm-elf. What does it even do ? Does it just force me to call gcc in command line using arm-elf-gcc instead of gcc or does it change some internal options of my gcc ?
So far I have prepared makefile but I am still not sure about compiler options. I have not changed any gcc configure options and I call compiler with such flags:
CFLAGS = -Wall -std=c99 -march=armv7-m -mtune=cortex-m0
Can I prepare toolchain just with calling gcc with proper arguments or do I need to make some changes in gcc configuration ?
GCC and its target
GCC is always configured to emit binaries for a specific target. So normally the gcc which is already available on Linux has the target "i486-linux-gnu". You can't cross-compile to an ARM target using this compiler.
So you need to install another GCC configured for that target; then GCC and the other programs normally have a prefix indicating the target: In your case the prefix is arm-none-eabi, and then you call that GCC using arm-none-eabi-gcc. You can have multiple GCC installations, they do not interact (if they interact, you have probably screwed up something - always install in separate directories, if you do it manually).
Installing
If your Linux distribution provides a package, you could just install that one (on Debian this is "gcc-arm-none-eabi").
You can download a pre-compiled package: GNU Tools for ARM Embedded Processors.
You can try to compile one. Not really easy, if you want correct multi-libs.
If your Linux distribution provides a package > 4.8.0, you should try that one.
If you want to have multiple versions installed (and be able to switch between them easily), the second option is possibly better. I stopped compiling a GCC for ARM when the second option was available.
Cross-compiling
In your Makefile you have to make sure that the cross-compiler is used. You could use $(CC) in your Makefile, and assign it like this:
TOOLCHAIN = arm-none-eabi-
CC = $(TOOLCHAIN)gcc
Compiler flags for Cortex-M0 are -mcpu=cortex-m0 -mthumb -mfloat-abi=soft which is by convention assigned to CFLAGS
CFLAGS += -mcpu=cortex-m0 -mthumb -mfloat-abi=soft
Then a (simple) rule to compile .c to .o looks like
%.o: %.c
$(CC) $(CFLAGS) -o $# -c $<
Tutorials which use the arm-elf- prefix are out-dated. Currently arm-none-eabi- is in use.
If one installs an R package that requires compilation via
R CMD INSTALL package.tar.gz
from the bash, R uses by default the gcc compiler. It happened now that my R-package throws a warning on Cran with a 'clang' compiler setup, that doesn't appear using the gcc compiler.
In order to reproduce the warning now on my local machine, I would like to adjust the local compiler settings to those used on the Cran-check servers.
I found out that it should be possible to change the R default compiler by creating a Makevars.in file somewhere in the home folder, but I cannot find where it has to be located and what has to be written there in order to make R to use 'clang' with certain warning flags enabled instead of 'gcc'.
Has anybody already switched on his/her Linux system the R default compiler from gcc to clang and could give me a hint how to do that?
My favourite method (and I think I detailed that here before) is to use the file ~/.R/Makevars where I set
CFLAGS += -O3 -Wall -pipe -pedantic -std=gnu99
CXXFLAGS += -O3 -Wall -pipe -Wno-unused -pedantic
#VER=-4.6
#VER=-4.7
VER=-4.8
CC=ccache gcc$(VER)
CXX=ccache g++$(VER)
SHLIB_CXXLD=g++$(VER)
FC=ccache gfortran
F77=ccache gfortran
MAKE=make -j8
#CXX=clang++
#CC=clang
and more as it also allows you to switch to clang++ instead of g++ and more.
I use ccache here too in order to accelerate repeated builds -- very useful for R packages where you may alter the package code but not the src/ files.
An alternative approach would a shell-script wrapper in which you set CC, CXX and everything else you want to modify.
I am trying to cross-compile linux for an ARM architecture.
The host is an X86 machine running ubuntu-jaunty. I downloaded a cross-compile toolchain for ARM from http://ftp.arm.linux.org.uk/pub/armlinux/toolchain/. I downloaded the 2.95.3 version of the toolchain.
The problem I am having is that GCC is passing in some default flags by itself that is causing GCC to then output error:
/usr/local/arm/2.95.3/bin/arm-linux-gcc -specs=/home/feroze/wnr834m/marvell_WNR834M/gcc_specs -D__KERNEL__ -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/include -Wall -Wstrict-prototypes -Wno-trigraphs -Os -fno-strict-aliasing -fno-common -DLED_DUAL_COLOR -DFOR_ROUTER -I/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk/arch/arm/mach-mv88fxx81/Soc/gpp/ -Uarm -fno-common -pipe -mapcs-32 -D__LINUX_ARM_ARCH__=5 -march=armv5 -mtune=arm9tdmi -mshort-load-bytes -msoft-float -Uarm -march=strongarm -DKBUILD_BASENAME=main -c -o init/main.o init/main.c
cc1: bad value (strongarm) for -march= switch
make[1]: *** [init/main.o] Error 1
make[1]: Leaving directory `/home/feroze/wnr834m/marvell_WNR834M/linux-88fxx81-1_1_3_gtk'
I checked the whole makefile, and could not find any place where LINUX_ARM_ARCH_5 and -march=armv5 are being defined. I am defining -march=strongarm in the makefile, but then it gets appended by theh ARMv5 defines.
So, I created a defs file from gcc, modified it to only have options for ARMv4, and then used it by specifying the -specs= option. However, that still doesnt solve the problem.
Can somemone help? How do I resolve this?
Thanks!
feroze
The -march flag is set in arch/ARM/Makefile, and depends on the machine you selected in your config file. If you don't want the armv5 flag, be sure to select the correct architecture in the config file.
You should assume the kernel appended CFLAGS are right (provided your config is ok) and if your toolchain does not support one of them, then you have no choice but to cross compile a toolchain by yourself, using the original crosstol script that should work with 2.95.3
Edit : original answer
What are you trying to build ?
a 2.95.3 toolchain is fairly ancient. You should try a more recent toolchain. You can find a precompiled one here
Pick the EABI one to start.
This is not a direct answer to your problem, but if you are building the linux kernel, you should not need to mess with the Makefiles. You will get more help if you can get a more "standard" toolchain.
This won't strictly help you eliminate the issue, but you can do gcc -dM -E <empty_file.c> or gcc -dM -E -x c /dev/null to print out a listing of all the predefined #defines for gcc. Combine -dM with another flag like your -march and you might be able to track down what's causing your #define issue.
Be sure to check your environment variables, as they can persuade make to do unexpected things.
If the Makefile includes another file, it could be modifying CFLAGS before CC is called. Can you print the contents of CFLAGS just before the CC call?
On Linux (kernel 2.6.5) our build system calls gcc with -D_REENTRANT.
Is this still required when using pthreads?
How is it related to gcc -pthread option? I understand that I should use -pthread with pthreads, do I still need -D_REENTRANT?
On a side note, is there any difference that you know off between the usage of REENTRANT between gcc 3.3.3 and gcc 4.x.x ?
When I use -pthread gcc option I can see that _REENTRANT gets defined. Will omitting -D_REENTRANT from command line make any difference, for example could some objects be compiled without multithreaded support and then linked into binary that uses pthreads and will cause problems?
I assume it should be ok just to use: g++ -pthread
> echo | g++ -E -dM -c - > singlethreaded
> echo | g++ -pthread -E -dM -c - > multithreaded
> diff singlethreaded multithreaded
39a40
> #define _REENTRANT 1
We're compiling multiple static libraries and applications that link with the static libraries, both libraries and application use pthreads.
I believe it was required at some stage in the past but want to know if it is still required. Googling hasn't returned any recent information mentioning -D_REENTRANT with pthreads. Could you point me to links or references discussing the use in recent version of kernel/gcc/pthread?
Clarification: At the moment we're using -D_REENTRANT and -lpthread, I assume I can replace them with just g++ -pthread, looking at man gcc it sets the flags for both preprocessor and linker. Any thoughts?
For me the best answer was the comment from pts if only he bothered to submit it as answer:
You investigated properly and answered
your own question. Use g++ -pthread,
it is equivalent to g++ -lpthread -D_REENTRANT.
Using g++ -D_REENTRANT would be different,
it may not set all the linker flags. –
pts May 18 at 0:30
From the gcc info pages:
`-pthread'
Adds support for multithreading with the "pthreads" library. This
option sets flags for both the preprocessor and linker.
So just the -pthread flag should be sufficient. I wouldn't recommend only passing it to some of your code, however.
As Chris suggested in the comments, using gcc -dumpspecs on Linux does indeed confirm that it sets preprocessor flags as well:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
gcc's -pthreads flag sets the relevant compiler and linker flags necessary for pthreads support on the platform you're on.
You're right, on linux x86 (and probably many other platforms), that's equivalent to '-D_REENTRANT -lpthread' but that's not necessarily true on all platforms.
(For at least some time, on aix, -pthread caused g++ to link in a completely different libstdc++.a. I don't know if that's still the case now, though...)