Prefer sysroot headers over headers in the toolchain using gcc - c++

I'm trying to cross-compile a simple code snippet
1 #include <sys/socket.h>
2 #include <stdio.h>
3
4 int main()
5 {
6 printf("%d\n", SOL_NETLINK);
7 return 0;
8 }
with arm-linux-gnueabihf-g++ (from Ubuntu) against Raspbian sysroot with --sysroot switch set to $SYSROOT
The compilation fails with this error:
test.cpp:6:20: error: ‘SOL_NETLINK’ was not declared in this scope
Even though $SYSROOT/usr/include/arm-linux-gnueabihf/bits/socket.h contains
the needed define.
So I figured that toolchain contains the mentioned header as well and it's included first. The latter header somehow doesn't have this SOL_NETLINK define. So I need a way to tell the compiler to prefer the toolchain's headers to sysroot's ones.
> arm-linux-gnueabihf-g++ -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

#include <sys/socket.h> will include a file which is under the folder {include path}/sys/socket.h.
Include path can be any folder that you add with various options like gcc -I or --includedir. In addition there are some default include path, which you should be able to see with gcc -xc++ -E -v -.
Using gcc "-I" option will put the include path to search first, before any of the default include paths.
Now, this should give you enough information to understand that the include you give can't point to the file $SYSROOT/usr/include/arm-linux-gnueabihf/bits/socket.h as it isn't end with {include path}/sys/socket.h

Use -isystem flag with $SYSROOT/usr/include/arm-linux-gnueabihf
Albeit GCC can resolve triple (arm-linux-gnueabihf part) in the path, but it won't do so with --sysroot option.

Related

Installing g++ = 7.5.0 with support for Cilk Plus

I want to use https://github.com/yushangdi/parChain however I can't fullfil requirement:
Compiler:
g++ = 7.5.0 with support for Cilk Plus
I have a problem with installing GCC with Cilk. I try to follow some tutorials from the websites but any of them doesn't work correctly. Unfortunately, the Cilk project was transformed into Intel's project many documentation URLs don't work anymore. I got following error after run $./pc_exp.sh
In file included from sequence.h:27:0,
from framework.C:1:
parallel.h:25:10: fatal error: cilk/cilk.h: Not found
#include <cilk/cilk.h>
^~~~~~~~~~~~~
compilation terminated.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-6ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-6ubuntu2)
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-6ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-6ubuntu2)
I need to run this on both: Ubuntu 20.04 and Centos 7. I'm not Linux/c++ experienced user. Can you help me with some tutorials?
I recommend you consider OpenCilk, an active open source project that picks up where Cilk Plus left off. OpenCilk 2.0 was released just a couple weeks ago, and it definitely supports Ubuntu 20.04. (Not sure about Centos.) Please see https://www.opencilk.org for tutorials on programming with Cilk (which is based on LLVM btw).

How can I enable -ffast-math with pragma in a bit old g++?

For some reason, I want to enable "-ffast-math" via pragma in g++.
But currently it doesn't work.
It seems #pragma GCC optimize("fast-math") is eventually ignored although g++ recognizes it at least during parsing this pragma sentence.
Here is a snippet I used for checking this issue(borrowed from here):
#pragma GCC optimize("fast-math")
#include <iostream>
#include <limits>
int main() {
double d = 1.0;
double max = std::numeric_limits<double>::max();
d /= max;
d *= max;
std::cout << d << std::endl;
return 0;
}
When I compiled this putting -ffast-math explicitly, this program outputs 0:
$ g++ poc.cpp -ffast-math -Wall
$ ./a.out
0
On the other hand, when I didn't put this flag, it shows 1 though I wrote the pragma sentence at least:
$ g++ poc.cpp -Wall
$ ./a.out
1
Since I confirmed other optimizations such as #pragma GCC optimize("O3") work fine(I checked with objdump), I think somehow g++ ignores only fast-math.
Does anyone know the reason or have a workaround for this?
Here is the information of g++ in my environment:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.10' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)

GCC7 ARMv7-a compilation error in standard headers

I am trying to compile my C++1z application for the ARMv7-a architecture using GCC7. I tested and have the application working in Ubuntu 16.04 (x86_64), but when I try compiling it on the ARM device (Ubuntu 14.04) I end up with compilation errors in the standard headers. One example of the errors is:
In file included from /usr/include/c++/7/bits/ios_base.h:46:0,
from /usr/include/c++/7/ios:42,
from /usr/include/c++/7/istream:38,
from /usr/include/c++/7/sstream:38,
from /usr/include/c++/7/complex:45,
from /home/ubuntu/work/git_rep/surrogate/external/opencv/modules/core/include/opencv2/core/cvstd.inl.hpp:47,
from /home/ubuntu/work/git_rep/surrogate/external/opencv/modules/core/include/opencv2/core.hpp:3217,
from /home/ubuntu/work/git_rep/surrogate/external/opencv/modules/videoio/include/opencv2/videoio.hpp:46,
from /home/ubuntu/work/git_rep/surrogate/service/streaming/video/stereo_camera_stream.h:5,
from /home/ubuntu/work/git_rep/surrogate/service/streaming/video/stereo_camera_stream.cc:1:
/usr/include/c++/7/system_error: At global scope:
/usr/include/c++/7/system_error:151:31: error: ‘error_category’ does not name a type; did you mean ‘error_code’?
error_code(int __v, const error_category& __cat) noexcept
^~~~~~~~~~~~~~
error_code
/usr/include/c++/7/system_error:160:27: error: ‘error_category’ does not name a type; did you mean ‘error_code’?
assign(int __v, const error_category& __cat) noexcept
^~~~~~~~~~~~~~
error_code
/usr/include/c++/7/system_error:180:11: error: ‘error_category’ does not name a type; did you mean ‘error_code’?
const error_category&
^~~~~~~~~~~~~~
error_code
/usr/include/c++/7/system_error:199:11: error: ‘error_category’ does not name a type; did you mean ‘error_code’?
const error_category* _M_cat;
^~~~~~~~~~~~~~
error_code
/usr/include/c++/7/system_error: In constructor ‘std::error_code::error_code()’:
/usr/include/c++/7/system_error:149:20: error: class ‘std::error_code’ does not have any field named ‘_M_cat’
: _M_value(0), _M_cat(&system_category()) { }
^~~~~~
/usr/include/c++/7/system_error:149:28: error: ‘system_category’ was not declared in this scope
: _M_value(0), _M_cat(&system_category()) { }
^~~~~~~~~~~~~~~
/usr/include/c++/7/system_error:149:28: note: suggested alternative:
/usr/include/c++/7/system_error:134:40: note: ‘std::_V2::system_category’
_GLIBCXX_CONST const error_category& system_category() noexcept;
^~~~~~~~~~~~~~~
The compiler recommends replacing std::system_category with std::_V2::system_category, as though there would be an error in the standard header. I compared the header against the header I used when compiling my application for a x86_64 environment, and they seem the same, which leaves me guessing as to why the compilation targeting ARMv7-a is failing.
I am using CMake to build the source code, so - to the best of my knowledge - there should be no other differences in configuration apart from system specific options. I compared the configurations of the two compilers I used by running gcc -v. They are as follows:
GCC7 (x86_64)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-1ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04)
GCC7 (ARMv7-a)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/7/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 7.2.0-1ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --disable-werror --enable-multilib --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 7.2.0 (Ubuntu/Linaro 7.2.0-1ubuntu1~14.04)
One of the differences in the configuration that stood out for me is --with-default-libstdcxx-abi, which is set to gcc4-compatible for ARMv7-a and new for x86_64, as it influences the implementation of the error_category class.
I am not sure how it could cause the compile error I am seeing though, so this is where I turn to you. What could be the cause and a possible fix for the compile error I described?
Edit
After splitting a header file included by the affected file into two separate headers and - resultingly - compilation units, the compile errors turned into linker errors, all similar to the following:
../../lib/libservice.a(duplicate_camera_stream.cc.o):duplicate_camera_stream.cc:(.text+0x12c4): first defined here
../../lib/libservice.a(simulated_video_stream.cc.o): In function `std::make_error_code(std::io_errc)':
simulated_video_stream.cc:(.text+0x100d8): undefined reference to `std::iostream_category()'
../../lib/libservice.a(simulated_video_stream.cc.o): In function `std::make_error_condition(std::io_errc)':
simulated_video_stream.cc:(.text+0x10110): undefined reference to `std::iostream_category()'
This led me to thinking that there might be an incompatibility with the C++ standard of the OpenCV libraries that I am statically linking against.
Solution
After compiling the source code of OpenCV using the same C++ standard as the rest of my code, the linking errors dissapeared, and the build was successfull.
Could it be that by including OpenCV headers in - and linking libraries of an older C++ standard against - an application with a different C++ standard; linker and/or compile errors could occur?

BeagleBoneBlack Cross Compile on Mac Error

I use gcc-linaro-arm-linux-gnueabihf-2014.05 for cross-compling BeagleBoneBlack (Rev c) on my mac using eclipse.
I used this weblog instructions: http://www.welzels.de/blog/en/arm-cross-compiling-with-mac-os-x/
when I compile the hello world sample it works "ok" on BBB, but the problem is when I compile my full program using pthread and stdio and etc... it fails to run on BBB with the following error:
./NewDCU.elf: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./NewDCU.elf)
for more details about my BBB:
root#arm:/home/ubuntu# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)
It seems that the problem is related to missmatch of toolchain complier version and my corresponding libraries on BBB.
I downgraded my Linaro toolchain to 4.8 from this link:
http://www.welzels.de/blog/projekte/arm-cross-toolchain/

How to link gfortran when I compile?

I use ubuntu 12.04, my Makefile FC:gfortran, but I couldn't compile,
I checked on it, it installed(my gcc upgraded from 4.6.3 to 4.7)
How do I link to it?
I tried pkg-config --cflags --lib gfortran or gtkxxx, it says not in the pkg_config_path
I checked gfortran: COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' -with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
You don't need pkg-config to use gfortran; you just need to compile and link with the gfortran executable (and you can also use gfortran to link C code with Fortran code, and you could probably link using gcc with -lgfortran)
BTW, pkg-config accepts the --list-all option; with the command
pkg-config --list-all |grep -i gtk
you can understand that GTK is in fact gtk+-x11-3.0
You should also read the documentation of GFORTRAN; it has a chapter about mixed-language-programming
Of course you need to install the gfortran, gfortran-4.7 and libgfortran-4.7-dev packages