GCC7 ARMv7-a compilation error in standard headers

血红的双手。 提交于 2019-12-11 18:41:10

问题


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?

来源:https://stackoverflow.com/questions/46884363/gcc7-armv7-a-compilation-error-in-standard-headers

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!