My gcc version is 9.3.0
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
According to gcc 9.3 manual
-mmanual-endbr
Insert ENDBR instruction at function entry only via the cf_check function
attribute. This is useful when used with the option ‘-fcf-protection=branch’
to control ENDBR insertion at the function entry.
From my understand, if I compile something using following command:
gcc -fcf-protection=branch -mmanual-endbr sth.c -o sth
The main function hasn't cf_check attribute, so there should isn't endbr64 at entry of main.
But it turns out still has endbr64 at entry.
So, how to make GCC not to generate endbr64?
Thanks.
I have a project that compiles for an RX600 with renasas' gcc compiler (from now on rx-elf-gcc). But I was wondering, shouldn't I be able to compile it with standard gcc? And if, how?
I'm making a docker container for the project, and I would prefere if I did not have to install renesas' compiler, installing it and supplying the activation code, etc.
I have found this piece of documentation, that got me started
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/RX-Options.html
I then expected to be able to do something like:
$ gcc -mcpu=rx600 -mlittle-endian-data dummy.c
But it gives the error:
gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
gcc: error: unrecognized command line option ‘-mlittle-endian-data’
I have tried using -mtune instead, but it seems rx is not a valid option
$ gcc -mtune=rx600 dummy.c
cc1: error: bad value (‘rx600’) for ‘-mtune=’ switch
cc1: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 bonnell atom silvermont slm knl intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2 generic
So, can I add a new hardware model to my installation? Or will these models just simply redirect my to rx-elf-gcc?
As a side note:
$ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ rx-elf-gcc --version
rx-elf-gcc (GCC_Build_20180315) 4.8.4.201801-GNURX
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And the following works:
$ rx-elf-gcc -mcpu=rx600 -mlittle-endian-data -c dummy.c
I have a very large project that I'm trying to migrate from GNU make to cmake. As such, I think having intermediary files containing various variables is a good way to go.
Since I'm just starting out, this is what I have for top_directory/vars/CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
set(VARIABLE "value")
This way, in another folder, I can add this line to that CMakeLists.txt:
add_subdirectory(top_directory/vars)
However, when trying to run cmake on top_directory/vars/CMakeLists.txt, I receive the following error:
me#host:/tmp>cmake .
-- The C compiler identification is unknown
-- The CXX compiler identification is GNU 7.3.1
-- Check for working C compiler: /usr/bin/g++
-- Check for working C compiler: /usr/bin/g++ -- broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/usr/bin/g++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /tmp/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/gmake" "cmTC_607e9/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_607e9.dir/build.make CMakeFiles/cmTC_607e9.dir/build
gmake[1]: Entering directory '/tmp/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_607e9.dir/testCCompiler.c.o
/usr/bin/g++ -o CMakeFiles/cmTC_607e9.dir/testCCompiler.c.o -c /tmp/CMakeFiles/CMakeTmp/testCCompiler.c
/tmp/CMakeFiles/CMakeTmp/testCCompiler.c:2:3: error: #error "The CMAKE_C_COMPILER is set to a C++ compiler"
# error "The CMAKE_C_COMPILER is set to a C++ compiler"
^~~~~
gmake[1]: *** [CMakeFiles/cmTC_607e9.dir/build.make:66: CMakeFiles/cmTC_607e9.dir/testCCompiler.c.o] Error 1
gmake[1]: Leaving directory '/tmp/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:126: cmTC_607e9/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt
-- Configuring incomplete, errors occurred!
See also "/tmp/CMakeFiles/CMakeOutput.log".
See also "/tmp/CMakeFiles/CMakeError.log".
Now I can force it by adding -DCMAKE_C_COMPILER=gcc, but that really defeats the portability aspect.
So my question is: is this the right way to be making "variable" CMake files and why does CMake incorrectly detect my C compiler?
Helpful Information:
cmake --version
cmake version 3.11.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
gcc --version
gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
If there is any additional information I can provide, then please let me know.
I'm following some code from here which is as follows:
The OP says that you can link with -lbfd -lopcodes.
However, for OpenSuSE I've found that for libbfd I need -lbfd -liberty -lz -ldl
When trying to compile, here is my results:
make
gcc ./main.c -lbfd -liberty -lz -ldl -lopcodes -g -o bfd_se
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libopcodes.a(arm-dis.o): In function `print_insn_neon':
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/arm-dis.c:2927: undefined reference to `floatformat_ieee_single_little'
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/arm-dis.c:2927: undefined reference to `floatformat_to_double'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libopcodes.a(m68k-dis.o): In function `print_insn_arg':
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/m68k-dis.c:1103: undefined reference to `floatformat_m68881_ext'
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/m68k-dis.c:1103: undefined reference to `floatformat_to_double'
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/m68k-dis.c:1099: undefined reference to `floatformat_ieee_double_big'
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/m68k-dis.c:1099: undefined reference to `floatformat_to_double'
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/m68k-dis.c:1095: undefined reference to `floatformat_ieee_single_big'
/home/abuild/rpmbuild/BUILD/binutils-2.24/build-dir/opcodes/../../opcodes/m68k-dis.c:1095: undefined reference to `floatformat_to_double'
collect2: error: ld returned 1 exit status
Makefile:4: recipe for target 'bfd_se' failed
make: *** [bfd_se] Error 1
What other flags do I need to add to have this program compile? I see the error is related to different architectures, but I'm not trying to cross compile.
Thanks!
useful information:
uname -a
Linux node 4.0.5-THS_on #1 SMP PREEMPT Thu Jun 18 16:37:06 CDT 2015 x86_64 x86_64 x86_64 GNU/Linux
gcc --version
gcc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
objdump --version (it uses libbfd and libopcodes)
GNU objdump (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
Most of the time libbfd and libopcodes does not come as shared libraries in standard distributions (because they are not meant to be linked to). You must either link to the static libraries (libbfd.a and libopcodes.a) or recompile your distribution package and include the shared libraries in it (.so files).
So, to make it clear, try:
gcc ./main.c -liberty -lz -ldl -g -o bfd_se /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libopcodes.a /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libbfd.a
I have two gcc compilers installed on my system, one is gcc 4.1.2 (default) and the other is gcc 4.4.4. How can I check the libc version used by gcc 4.4.4, because /lib/libc.so.6 shows the glibc used by gcc 4.1.2, since it is the default compiler.
even easier
use ldd --version
This should return the glibc version being used i.e.
$ ldd --version
ldd (GNU libc) 2.17
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
...
which is the same result as running my libc library
$ /lib/libc.so.6
GNU C Library (GNU libc) stable release version 2.17, by Roland McGrath et al.
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
...
Write a test program (name it for example glibc-version.c):
#include <stdio.h>
#include <stdlib.h>
#include <gnu/libc-version.h>
int main(int argc, char *argv[]) {
printf("GNU libc version: %s\n", gnu_get_libc_version());
exit(EXIT_SUCCESS);
}
and compile it with the gcc-4.4 compiler:
gcc-4.4 glibc-version.c -o glibc-version
When you execute ./glibc-version the used glibc version is shown.
Use -print-file-name gcc option:
$ gcc -print-file-name=libc.so
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so
That gives the path. Let's examine the file:
$ file $(gcc -print-file-name=libc.so)
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libc.so: ASCII text
$ cat $(gcc -print-file-name=libc.so)
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) )
The file is a linker script, which links the libraries in GROUP list.
On ELF platforms /lib/x86_64-linux-gnu/libc.so.6 is a position-independent executable with a dynamic symbol table (like that of a shared library):
$ file /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6: symbolic link to libc-2.31.so
$ file $(readlink -f /lib/x86_64-linux-gnu/libc.so.6)
/usr/lib/x86_64-linux-gnu/libc-2.31.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=1878e6b475720c7c51969e69ab2d276fae6d1dee, for GNU/Linux 3.2.0, stripped
$ /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.9) stable release version 2.31.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 9.4.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs>.
gnu_get_libc_version identifies the runtime version of the GNU C Library.
If what you care about is the compile-time version (that is, the version that provided the headers in /usr/include), you should look at the macros __GLIBC__ and __GLIBC_MINOR__. These expand to positive integers, and will be defined as a side-effect of including any header file provided by the GNU C Library; this means you can include a standard header, and then use #ifdef __GLIBC__ to decide whether you can include a nonstandard header like gnu/libc-version.h.
Expanding the test program from the accepted answer:
#include <stdio.h>
#ifdef __GLIBC__
#include <gnu/libc-version.h>
#endif
int
main(void)
{
#ifdef __GLIBC__
printf("GNU libc compile-time version: %u.%u\n", __GLIBC__, __GLIBC_MINOR__);
printf("GNU libc runtime version: %s\n", gnu_get_libc_version());
return 0;
#else
puts("Not the GNU C Library");
return 1;
#endif
}
When I compile and run this program on the computer I'm typing this answer on (which is a Mac) it prints
Not the GNU C Library
but when compiled and run on a nearby Linux box it prints
GNU libc compile-time version: 2.24
GNU libc runtime version: 2.24
Under normal circumstances, the "runtime" version could be bigger than the "compile-time" version, but never smaller. The major version number is unlikely ever to change again (the last time it changed was the "libc6 transition" in 1997).
If you would prefer a shell 'one-liner' to dump these macros, use:
echo '#include <errno.h>' | gcc -xc - -E -dM |
grep -E '^#define __GLIBC(|_MINOR)__ ' | sort
The grep pattern is chosen to match only the two macros that are relevant, because there are dozens of internal macros named __GLIBC_somethingorother that you don't want to have to read through.
I doubt if you have more than one glibc installed in your system.But ldd -v <path/to/gcc-4.x> should give you the glibc used.
The easiest way is to use ldd which comes with glibc
Just run this command ldd --version :
dina#dina-X450LA:~$ ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu9) 2.23
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
Their is two additional ways to find out the glibc version:
Check the version of the installed glibc rpm package : this by runing this command
rpm -q glibc
Check the version of the used libc.so file. This way is a little bit more difficult. You can check it in this link: Linux: Check the glibc version
You can use strings command to check GLIBC version of compiler. Highest version is applicable.
ubuntu1604:extra$ strings ./arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc | grep GLIBC
GLIBC_2.3
GLIBC_2.8
GLIBC_2.14
GLIBC_2.4
GLIBC_2.11
GLIBC_2.2.5
GLIBC_2.3.4
Also, check the higher versioning symbol of the libc:
readelf -V /lib64/libc.so.6