My copy of clang seems to run with options like -Wimplicit-int and -Wreturn-type turned on by default. (Perhaps this is because the language is set to c11 by default.) I know I can turn these
off using -Wno-implicit-int and -Wno-return-type, but is there a way to do that by default? Maybe with an environment variable or rc file?
I'd also like to add a few options, like having it search /usr/local/include by default.
I'd also like turn off the -fcolor-diagnostics, -fshow-column, and -fno-caret-diagnostics options, which also seem to be on by default.
(This is clang-600.0.57 / Apple LLVM version 6.0 under MacOS
10.9.5, if it matters.)
As describe here you can use the MAKEFILES environment to define extra default target and flags (like a makefile include ), to define the default CFLAGS then use += to add extra param in your project specific CFLAGS
Related
I've been exploring compilers and cross compilers. I'm reading the GCC manual.
Specifically, there are these statements in the manual that I have queries regarding:
The linker searches a standard list of directories for the library. The directories searched include several standard system directories plus any that you specify with -L.
The -isystem and -idirafter options also mark the directory as a system directory, so that it gets the same special treatment that is applied to the standard system directories.
Alright, what are these "system directories"? On a Linux machine, what are the system directories for the native compiler?
And if I've built a cross compiler (like the one shown here: https://wiki.osdev.org/GCC_Cross-Compiler), what are the "system directories" with respect to this compiler?
Can I change the system directory when I build GCC? Moreover, Where does sysroot come into the picture?
The "standard" system directories aren't specific directories - it may vary across installations/distributions.
gcc has an option -print-search-dirs. Using which you can get the list of directories, it looks for.
Something like:
gcc -print-search-dirs | grep libraries | sed 's/libraries: =//g' | tr ':' '\n' | xargs readlink -f
It's the same for cross compiler's too (you'd call cross compiler's front-end instead of plain gcc).
--sysroot is straightward:
--sysroot=dir Use dir as the logical root directory for headers and libraries. For example, if the compiler normally searches for headers
in /usr/include and libraries in /usr/lib, it instead searches
dir/usr/include and dir/usr/lib.
If you use both this option and the -isysroot option, then the
--sysroot option applies to libraries, but the -isysroot option applies to header files.
The GNU linker (beginning with version 2.16) has the necessary support
for this option. If your linker does not support this option, the
header file aspect of --sysroot still works, but the library aspect
does not.
GCC is nothing if not configurable.
When you build an instance GCC, you need to completely specify the target environment. (Fortunately, most of this has already been done for you.) If necessary, you can tweak any of these settings before you do the build. The settings are described in detail in the GCC internals manual, but the particular ones you're interested in are in the chapter describing Target Macros, and particularly the section on Controlling the Compilation Driver. In this last section, you'll find descriptions of the various macros which define include paths. (Search for the word "include" in that page. Read everything you find :-); GCC documentation is not a tutorial.)
I have already known that the GCC's argument -finstrument-functions can hook the functions and the argument -finstrument-functions-exclude-file(functions)-list can exclude some files/functions to be traced.
But now I have a lot of files to be compiled and only some of them need to be traced. I wonder if I can include some specific functions/files to be traced, such as something like -finstrument-functions-include-file(functions)-list?
Thanks a lot!
GCC does not support this out-of-the-box (it's more a task for your build system). One common hack to achieve what you want is to write a shell wrapper which replaces GCC and adds flags where needed:
$ cat path/to/fake/gcc
#!/bin/sh
FLAGS=
if echo "$*" | grep -q 'myfile1.c'; then
FLAGS=-finstrument-functions
fi
exec /usr/bin/gcc "$#" $FLAGS
$ export PATH="path/to/fake:$PATH"
If you use cmake to build your project you may benefit from adding COMPILE_OPTIONS at a specific level. Use
add_compile_options()
for directory-wide settings
target_compile_options()
for target-specific settings and
set_source_files_properties()
for file specific settings.
In your case
set_source_files_properties(
myfile1.cc PROPERTIES COMPILE_FLAGS -finstrument-functions)
Recent GCC compilers can be extended by GCC plugins.
But now I have a lot of files to be compiled and only some of them need to be traced.
You should consider writing your own GCC plugin to do that job. See also this draft report.
You may configure your build automation tool (e.g. GNU make or ninja) to help you.
At last, some of your C code (e.g. #include-ed files) could be generated. Think of meta-programming approaches (e.g. with SWIG or ANTLR or Bison or GPP or your own C code generator), perhaps using X-macros.
I'm just getting started with autotools, and have followed A. Duret-Lutz's tutorial closely to get a working C hello world that uses GNU gettext.
The AM_CFLAGS and AM_LDFLAGS are set appropriately in the Makefile.am, and the code compiles and runs successfully.
The issue is that autoconf is not searching in the directories that AM_CFLAGS and AM_LDFLAGS is telling the compiler to search, and as a result not defining the HAVE_GETTEXT_H, HAVE_LIBINTL, etc. macros in the config.h.
How can I get the configure.ac to supplement the library and include directories it searches when using AC_CHECK_LIB and AC_CHECK_HEADERS?
I think I misread the original question but since nothing in my other answer is incorrect per se I'll add another answer.
In order to use custom paths in AC_CHECK_HEADER and AC_CHECK_LIBS one has to (temporarily) set CFLAGS and LDFLAGS accordingly:
CFLAGS_backup="${CFLAGS}"
LDFLAGS_backup="${LDFLAGS}"
CFLAGS="-I/path/to/an/additional/include/ ${CFLAGS}"
LDFLAGS="-L/path/to/the/lib/ ${LDFLAGS}"
AC_CHECK_HEADER(...)
AC_CHECK_LIB(...)
## reset CFLAGS and LDFLAGS
CFLAGS="${CFLAGS_backup}"
LDFLAGS="${LDFLAGS_backup}"
Within AC_CHECK_* you'd typically set GETTEXT_CFLAGS or LIBINTL_LIBS as variables and export them for use in automake per AC_SUBST([GETTEXT_CFLAGS]) and AC_SUBST([LIBINTL_LIBS]) respectively.
Unfortunately, you cannot access AM_CFLAGS or AM_LDFLAGS in configure.ac.
Now in Makefile.am you can use
AM_CFLAGS = $(GETTEXT_CFLAGS) <other stuff>
AM_LDFLAGS = $(GETTEXT_LIBS) <other stuff>
For convenience, typically, you'd expose a parameter to the user as well, either via AC_ARG_WITH or AC_ARG_VAR, so they can use --with-gettext or LIBINTL_LIBS=... along with the configure command.
Seeing as autoconf is really only m4 you could wrap the above in a macro yourself. And seeing as we talk about gettext here, there is already such a thing: AM_GNU_GETTEXT, an m4 macro that you could use in your configure.ac after you called gettextize.
Instead of AC_CHECK_HEADER, use AC_CHECK_HEADERS, that defines tokens of the form HAVE_<HEADER>_H. The singular form expects you to define things yourself using the ACTION-IF-FOUND (2nd argument).
For AC_CHECK_LIB there is no such comfort, you must use the ACTION-IF-FOUND (3rd argument) and AC_DEFINE whatever is needed.
Additionally there will be shell variables ac_cv_header_<HEADER>_h and ac_cv_lib_<LIBRARY>_<FUNCTION> set.
I have a simple Autotools C project (not C++), whose skeleton was created for me by Eclipse CDT (Juno).
CFLAGs (by inspection) seem to be -g -O2.
I want all of the generated make files to also have -std=gnu99 appended to the CFLAGs, because I use for (int i = 0; i < MAX; i++) and similar.
I can obviously hack the Makefile, but this gets overwritten on ./configure.
Where is the correct place to add (or change) CFLAGs which are required by the code (as opposed to those CFLAGs which the user might want to change)?
P.S. I'd like to do this by editing a text file (such as Makefile.am or configure.ac), rather than clicking a box in Eclipse, if possible.
Just run into the same problem.
Here is the solution, just add the CFLAGS at the end of the configure options:
If you want to do this by editing configure.ac, just add CFLAGS="$CFLAGS something" into configure.ac
If you mean to parameters for the compiler than see attached. (c++ build/setting/Misc)
In Eclipse Neon CDT, you also have a "Dialect" setting as shown below:
Is there a way to inhibit the default library path search with gcc? -nostdinc does this for the include path search, but -nostdlib, either by omission or by design, only inhibits the -lc -lgcc etc. but not the library search paths.
You should be able to do this with spec files (although fiddling with these seems like something of a dark art to me...).
If you look at the output of gcc -dumpspecs, the link_command spec is the one that builds the actual command that is invoked. Digging through some of the other specs it references, the link_libgcc spec, which is usually defined (for native compilers at least) as:
*link_libgcc:
%D
is the culprit:
%D
Dump out a -L option for each directory that GCC believes might contain startup files. If the target supports multilibs then the current multilib directory will be prepended to each of these paths.
You can override it by creating a file (e.g. my.specs) which substitutes paths of your choice:
*link_libgcc:
-L/foo/bar -L/blah/blah
and then passing -specs=my.specs to gcc.
Supposing the underlying loader is ld you might be able to redirect its whole load path with
--sysroot=directory
(I don't remember the option that you have to use to pass loader arguments to gcc, but there is one...)
You could either have "directory" be something bogus, where no libraries are found, or mimic the directory layout for your own project.
You can try -nodefaultlibs to avoid all the default libraries, then use -L and -l to add-back the libraries you want in the directories you want.
Directories specified on the command-line with the -L option should have priority over the default directories.
How about just setting the LIBRARY_PATH environment variable?
If I understand the question correctly, you want to do something like forcing the linker to look at a local library path before the default path, so you can just explicitly set that variable to control the order.