I want to know what C language standard is my current installation of gcc following by default. I ran info gcc and it gave -std=standard.
What does -std=standard mean?
I was expecting something like -std=gnu11
OS: linux mint 19.1
gcc version: 7.4.0,
gcc came pre-installed with the OS
I looked into online manual here:
https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Standards.html#C-Language
but I didn't find any default standard named "standard". Instead I found that it should be "gnu11"
info gcc response:
...
OPTIONS
Option Summary
Here is a summary of all the options, grouped by type. Explanations
are in the following sections.
Overall Options
-c -S -E -o file -x language -v -### --help[=class[,...]]
--target-help --version -pass-exit-codes -pipe -specs=file
-wrapper #file -fplugin=file -fplugin-arg-name=arg
-fdump-ada-spec[-slim] -fada-spec-parent=unit -fdump-go-spec=file
C Language Options
-ansi -std=standard -fgnu89-inline
-fpermitted-flt-eval-methods=standard -aux-info filename
-fallow-parameterless-variadic-functions -fno-asm
...
The word "standard" is in a cursive font. It's a template, it's not a "default gcc standard gcc uses by default", it's a template to be filled by the user with available option, the word "standard" stands there for gnu11 or c11 or for the standard you want to specify.
The same is with -fpermitted-flt-eval-methods=standard or -fno-builtin-function. You should specify the function that gcc should not use builtin for. This is a list of available options for C language in gcc, not list of default options gcc uses.
You can find the standard gcc is using by inspecting __STDC_VERSION__ macro. Or check the documentation. Quoting the link, for gcc 7.2.0:
The default, if no C language dialect options are given, is -std=gnu11.
In the context of -std=standard, standard is meant to represent one of the values listed in the Options Controlling C Dialect. It isn't meant to literally be the string standard; that results in an error:
gcc: error: unrecognized command line option ‘-std=standard’
Related
My LIBRARY_PATH variable is exported, but I still have to pass the -L option to gcc in order to link to my library.
If I understand the GCC documentation correctly 3.20 Environment Variables Affecting GCC, the LIBRARY_PATH environment variable should be looked so that I only have to specify the -l option.
When I run
gcc -Wall cog.c -L$HOME/lib -lutil
the program is compiled, and I get an a.out as expected.
If I run
gcc -Wall cog.c -lutil
I get an undefined reference error.
As far as I can tell, I've properly exported the environment variable.
cassiopeia~> export LIBRARY_PATH=$HOME/lib
cassiopeia~> ls $LIBRARY_PATH
libutil.a
Any clues?
For what it's worth, I'm using Fedora 23 64bit and gcc version 5.3.1 20160406 (Red Hat 5.3.1-6).
Your distro probably is multilib-enabled. If this is the case, all path strings to libraries are expanded with the architecture for this machine (typically 32-bit or 64-bit). So, if you specify
$HOME/lib
as your search path, multilib might expand it to
$HOME/lib/x86_64-linux/4.6
or
$HOME/lib/x86_32-linux/4.6
You can check if this is the case by invoking gcc once using
gcc --print-search-dirs
This makes gcc respond with all search paths in use for config and libraries.
In the gcc compiler we can provide a macro to be used by the preprocessor in C using -D flag (example- gcc -DN=10 test.c)
What is the flag that can be used to do the same in the clang compiler?
When I give the same -D option to the clang compiler on Windows, it gives an error:
"Directory not found."
Answer is the 2 comments from #cremno and #FUZxxl above.
The error wasn't coming from the clang compiler although it said clang error. Rather it was coming from the Windows cmd which looks for a directory after the '=' sign.
With IBM's cc compiler there is one option -brtl.
cc-brtl .....
This option does the following:-
-brtl Tells the linkage editor to accept both .so and .a library file types.
I am using gcc compiler now on ubuntu. I want to know what is the corresponding option in gcc to achieve
the same thing?
You don't need that option for gcc. The link editor will accept both so and a files by default, with so files being preferred. You can think of gcc as having the opposite behaviour to IBM's C compiler: The behaviour without any options is as if you provided -brtl to IBM's C compiler, while the option -static turns of dynamic linking (and thus causes gcc to not take so files into consideration), which is as if you didn't specify -brtl to IBM's C compiler.
I use gcc on Solaris 10 to build make program, and get the following information:
gcc: unrecognized option `-rdynamic'
After checking the rdynamic in gcc document, I get the following explantions:
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program.
My questions are:
(1) Although gcc prints "gcc: unrecognized option -rdynamic", the build is still success. Is this the default behavior of gcc?
(2) I replace "-rdynamic" with "-export-dynamic" in Makefile, and the build is success. Is there any side-effect of this substitution?
P.S. My gcc information:
bash-3.00# gcc -v
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6
You are using an obsolete version of gcc, but you refer to an up-to-date documentation. There is no such linker option for gcc-3.4.6, see https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Link-Options.html.
Try using -Wl,--export-dynamic option when linking instead.
I replace -rdynamic with -export-dynamic in Makefile, and the build is success. Is there any side-effect of this substitution.
This option is not documented, it may well do nothing, you need to check strace output what command line options it passes to the linker.
I am using gcc (Ubuntu 4.4.1-4ubuntu9) to compile a program that I'm writing, but it seems to vomit whenever it sees a // comment in my code, saying:
interface.c :##: error: expected expression before â/â token<
Does the gcc compile mode I'm using forbid // comments?
$ gcc -g -ansi -pedantic interface.c structs.h -c -I. -I/home/me/project/h
Why?
// comments are not allowed in old (pre 99) C versions, use /**/ (or remove the -ansi, that is a synonym for the C89 standard)
See C++ comments in GNU compiler documentation.
In GNU C, you may use C++ style comments, which start with // and continue until the end of the line. Many other C implementations allow such comments, and they are included in the 1999 C standard. However, C++ style comments are not recognized if you specify an -std option specifying a version of ISO C before C99, or -ansi (equivalent to -std=c89).
(Emphasis is mine because some of the posts claim that // are not allowed in standard C whereas that is only true for pre-99 standards).