I have upgraded my whole arch linux system today (12th May, 2022). gcc was also upgraded from v11.2 to v12.1. I tried compiling some of my programs with g++ (part of gcc compiler collection) by the following command:
g++ -O3 -DNDEBUG -Os -Ofast -Og -s -march=native -flto -funroll-all-loops -std=c++20 main.cc -o ./main
The program compiled perfectly and ran as excepted without any errors, but I got a warning:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
But, when the same program was compiled using v11.2 it produces zero number of errors and warnings.
My Questions:
What is the meaning of this warning?
How can I fix this?
Is this warning occurred due to upgrading gcc version to v12.1
Here's the g++ configuration on my machine:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
Apparently that is a recent change in the -flto option. With a little bit of variation in the google search I was able to find this mail conversation:
Likewise if people just use -flto and auto-detection
finds nothing:
warning: using serial compilation of N LTRANS jobs
note: refer to http://.... for how to use parallel compile
[...]
That is, teach users rather than second-guessing and eventually
blowing things up. IMHO only the jobserver mode is safe to
automatically use.
So this is about using the -flto options correctly. I could not manage to easily get a GCC 12 on my system and thus could not try it myself, but you can try -flto=1 or -flto=auto to get rid of the warning.
Anyway it seems that this warning is rather harmless. It just tells you that GCC uses 2 threads in parallel to do the link time optimization.
The exact semantics and effects of the -flto is (together with the other optimization options) described in detail in the GCC manual. By the way you should not spam optimization options like you do in your command line. For example specifying multiple -O... options will only have the effect of the last one of them. Unless you know exactly what you are doing and have carefully read the manual, just stick to use -O3 and you will be fine.
Related
I'm cross compiling for imx28 cpu with arm-fsl-linux-gnueabi:
[vladimir#vladimir src]$ arm-fsl-linux-gnueabi-g++ -v
Using built-in specs.
Target: arm-fsl-linux-gnueabi
Configured with: /work/arm-toolchains/tmp/src/gcc-4.4.4/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-fsl-linux-gnueabi --prefix=/work/arm_fsl_gcc_4.4.4_multilib --with-sysroot=/work/arm_fsl_gcc_4.4.4_multilib/arm-fsl-linux-gnueabi/multi-libs --enable-languages=c,c++ --with-pkgversion=4.4.4_09.06.2010 --enable-__cxa_atexit --disable-libmudflap --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-gmp=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --with-mpfr=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --with-ppl=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --with-cloog=/work/arm-toolchains/tmp/arm-fsl-linux-gnueabi/build/static --enable-threads=posix --enable-target-optspace --with-local-prefix=/work/arm_fsl_gcc_4.4.4_multilib/arm-fsl-linux-gnueabi/multi-libs --disable-nls --enable-symvers=gnu --enable-c99 --enable-long-long --enable-multilib --with-system-zlib --enable-lto
Thread model: posix
gcc version 4.4.4 (4.4.4_09.06.2010)
The following code line:
info->mask = 0xffffffffffffffff;
gives me following error:
warning: integer constant is too large for 'long' type
I tried close to everything, made sure int64_t is defined to long long int, even tried to typedef it manually, still, it gives me the error.
I also tried different -mcpu options.
Is there even a way to use int64_t on imx28, or should I just give up?
Based on your comment.
Try 0xFFFFFFFFFFFFFFFFLL or -1
I have been starting to try and learn how to utilize multithreading in c++, but the #include<thread> causes issues with the thread type being not declared in the scope. error: 'thread' was not declared in this scope. I have been doing research, and I have come across a lot of answers regarding how to solve this issue. Im presently at the understanding that my compiler, MinGW, doesn't support thread effectively, but I am not sure what to do with that information.
Any guidance on this matter is appreciated.
Also, I think this may be helpful. If I run gcc -v on my command line, I get this output:
Using built-in specs.
COLLECT_GCC=c:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/6.3.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-6.3.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --with-gmp=/mingw --with-mpfr --with-mpc=/mingw --with-isl=/mingw --prefix=/mingw --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-pkgversion='MinGW.org GCC-6.3.0-1' --enable-static --enable-shared --enable-threads --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --enable-libgomp --disable-libvtv --enable-nls
Thread model: win32
gcc version 6.3.0 (MinGW.org GCC-6.3.0-1)
edit: I've seen this webpage, https://github.com/meganz/mingw-std-threads, as a potential solution, but I don't think this works for me. Unless somehow I am putting the mingw-thread.h in the wrong folder.
I think the problem here is you did not tell the compiler using c++11 features. 'thread' is belonged to c++11 features, let try adding -std=c++11 into CXXFLAGS or CPPFLAGS and see if it resolves your problem
My psychic powers suggest your forgot the std:: namespace attribute. That would explain why thread is undefined, even with #include <thread>. The other answer about -std=c++11 is also steering you into the right direction. And don't forget the -pthread compiler/linker option.
$ cat foo.cpp
#include <thread>
#include <iostream>
void threadfunc()
{
std::cout << "Hello from the worker thread" << std::endl;
}
int main()
{
std::thread t(threadfunc);
t.join();
return 0;
}
$ g++ foo.cpp -std=c++11 -o foo -pthread
$ ./foo
Hello from the worker thread
When I am compiling gcc 8.2 on RHEL 6 (x86-64 arch) I am running into below issue
../../../libgcc/soft-fp/fixtfti.c:33:1: error: unknown type name 'TItype'; did you mean 'TFtype'?
TItype
^~~~~~
TFtype
../../../libgcc/soft-fp/fixtfti.c: In function '__fixtfti':
../../../libgcc/soft-fp/fixtfti.c:38:3: error: unknown type name 'UTItype'; did you mean 'UDItype'?
UTItype r;
^~~~~~~
UDItype
I compiled dependent gmp/mpfr/mpc/binutils/isl successfully and using them in my GCC compilation.
GCC configure command used:
../configure --prefix=/home/zk46w9e/apps/gcc-8.2.0-compliant/compiler/gcc-8.2/ --enable-gold --enable-libssp --enable-vtable-verify --enable-host-shared --enable-lto --with-mpc=/home/zk46w9e/apps/gcc-8.2.0-compliant/mpc/mpc-1.1.0 --with-mpfr=/home/zk46w9e/apps/gcc-8.2.0-compliant/mpfr/mpfr-4.0.1 --with-gmp=/home/zk46w9e/apps/gcc-8.2.0-compliant/gmp/gmp-6.1.2 --with-isl=/home/zk46w9e/apps/gcc-8.2.0-compliant/isl/isl-0.19 --enable-languages=c++ --disable-multilib --disable-nls --enable-threads=posix --enable-tls --enable-__cxa_atexit --enable-plugins
Still running into above issue. Can somebody throw some light?
I tried to compile GCC 32 bit , 64 bit individually by passing flags like -m32 etc which caused above error.
After passing --with-multilib-list=m32,m64 as option for GCC configure and reran the compilation, compilation went fine without any issues
thank you newkid for help
I'm new to C++. When I write
for (char* c : v)
{
cout << c;
}
I get
"range-based ‘for’ loops are not allowed in C++98 mode"
As far as I understand, I have to change my GCC version (or just mode?). My g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --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.7 --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 --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) `
Can't compile from vim (with c.vim plugin), sublime text3 and from terminal using gcc program.cpp and gcc -pedantic -std=c99 program.cpp.
I've downloaded gcc 4.8.1 but It's not deb package so can't install it properly. Also heard about C++11, C++14, C++98, C++99. Where/how can I get/install the latest version?
Solution for vim plugin c.vim:
Edit "c.vim/plugin/c.vim". Change this line
let s:C_CplusCFlags = '-Wall -g -O0 -c -std=c++11' " C++ compiler flags: compile, don't optimize
I've added "-std=c++11" and it works.
The range based for loop is part of C++11, so you will need to use -std=c++11 with G++ to enable the C++11 features.
As mentioned in the previous answer, you are attempting to use a feature of the latest C++ standard (called C++11) while compiling for older standard.
C++11 is the latest C++ standard and the only one supporting range based for.
Now you need to distinguish between the C++ standard and the compiler support for that standard.
Along the past few years, support for C++11 features was gradually added to the gcc compiler.
The following link shows which C++11 feature is supported by which gcc version:
C++0x/C++11 Support in GCC
As you can see, range based for was added in gcc 4.6, so you do not need gcc 4.8 in order to use this feature - gcc 4.6 or later will suffice.
When compiling, you will also need to tell the compiler which standard to compile against. The -std=whatever tells the compiler which standard to use.
You are currently using "-std=c99", telling the compiler to compile using an old C++ standard. Instead you need to set this flag to c++11. If this doesn't work on the gcc version you are using, try using "-std=c++0x" instead (C++0x is an old name of the C++11 standard.)
I'm trying to get crosstool-ng working with both C and C++. Even though I've selected C++ while using menuconfig, it doesn't seem to get built. The gcc compiler works as expected but not g++
I'm not sure what I'm doing wrong so any help would be appreciated.
I followed the steps found here:
Building embedded ARM systems with Crosstool-NG
$ arm-unknown-linux-gnueabi-cpp main.cpp -o test
arm-unknown-linux-gnueabi-cpp: main.cpp: C++ compiler not installed on this system
NOTE: there is no arm-unknown-linux-gnueabi-g++ found on in the bin directory.
I've tried cross-tool version 1.16.0 and 1.15.3
arm-unknown-linux-gnueabi-cpp -v
Using built-in specs.
Target: arm-unknown-linux-gnueabi
Configured with: /opt/crossArm/.build/src/gcc-4.3.2/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-unknown-linux-gnueabi --prefix=/opt/crossArm/.build/arm-unknown-linux-gnueabi/buildtools --with-local-prefix=/home/jgarvin/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot --disable-libmudflap --with-sysroot=/home/jgarvin/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot --enable-shared --with-pkgversion='crosstool-NG 1.16.0' --with-float=soft --enable-__cxa_atexit --with-gmp=/opt/crossArm/.build/arm-unknown-linux-gnueabi/buildtools --with-mpfr=/opt/crossArm/.build/arm-unknown-linux-gnueabi/buildtools --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --enable-languages=c
Thread model: posix
gcc version 4.3.2 (crosstool-NG 1.16.0)
Code
#include<iostream>
using namespace std;
int main(){
cout<<"Hello World"<<endl;
return 0;
}
In my build.log file I see C++ option turned on
[DEBUG] CT_CC_SUPPORT_CXX=y
I also see it in the config.log:
configure:3030: $? = 0
configure:3019: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-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 --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
From, http://briolidz.wordpress.com/2012/02/07/building-embedded-arm-systems-with-crosstool-ng/
Refine your configuration by running the menuconfig interface:
$ ./ct-ng menuconfig
In this step, navigate to the C Compiler menu. Then you can select C++ or de-select Java, Fortran, etc. Since crosstool-ng is just a bunch of scripts and patch files, it is very rare that a development build breaks things. You can always pull from the hg repository.
hg clone http://crosstool-ng.org/hg/crosstool-ng
cd crosstool-ng
./bootstrap
make
sudo make install
This will have the latest fixes. I have built arm cross compilers with C++ support many times using this method [including Canadian crosses for Mingw and i386 from an x86_64 host].
EDIT: I see that the wordpress link recommends a local install of ct-ng. The commands above do a full install, putting things in /usr/local. Also, it seems the OP did try to set menuconfig's C++ option. Try altering the sjlj value, use the latest version of ct-ng and install it. This produces an ARM Linux C++ cross-compiler on Ubuntu for me. The build.log output can be helpful in determining if ct-ng decided some configuration was impossible.
Finally, the mailing list crossgcc#sourceware.org doesn't require subscription afaik. The archives at http://sourceware.org/ml/crossgcc/ can be helpful. If you still have issues, I am sure someone on the mailing list will be able to help you.
EDIT: With the latest ct-ng installed try,
$ ct-ng arm-cortex_a15-linux-gnueabi #Alternate arm-yem-linux-gnueabi
$ ct-ng menuconfig # Tweak for your processor, gcc version, etc.
$ ct-ng build # Go have a coffee (or work on something else).
Sorry, your host compiler was made with Linaro. I was reading too much into your edit.
I was having similar issue. It turns out that I was looking at the wrong bin directory under .build. The final version of the toolchain was installed under ~/x-tools instead...
If you are still looking for an answer on compiling c++ on arm platform:
Install crosstool-ng:
tar xjf <ct-ng archive>
cd crosstool-ng-<numversion>
# reset of LD_LIBRARY_PATH is required to avoid issues with crosstool-ng
unset LD_LIBRARY_PATH
./configure prefix=<installDir>
#example ./configure prefix=/opt/cross-rpi
make
make install
#required to make sure you get the right on in case
export PATH=<installDir>/bin:$PATH
#check what version is on now.
which ct-ng
Now create and launch the configuration:
mkdir chain-build #the directory hosting the build files of your cross compil chain
cd chain-build
ct-ng menuconfig
Set options are relevant to the arm platform amongst other:
Paths and misc Options
Configure the maximum log level to see to WARN instead of INFO which totally clutters the logs and in my opinion makes them hard to use, way too much noise for the usual use case.
Target options Operating System
Target Architecture
arm
System
linux
Binary utilities
- Select the last version of binutils
C compiler
GCC : Select Show linaro Versions then select the lastest linaro gcc (more stable than non linaro, from experience)
C++ : Check it
Now build your toolchain
ct-ng build
# once done check the content of the bin dir
ls <yourChainInstallDir>/x-tools/arm-unknown-linux-gnueabi/bin
You should get something like this:
of all to compile c++ code you should only need g++. To check if g++ (for arm) works ok type
arm-unknown-linux-gnueabi-g++ -v
You should get something similar to this:
Using built-in specs.
COLLECT_GCC=x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/opt/cross1.19/x-tools/arm-unknown-linux-gnueabi/libexec/gcc/arm- unknown-linux-gnueabi/4.8.2/lto-wrapper
Target: arm-unknown-linux-gnueabi
[...]
blahblah
[...]
gcc version 4.8.2 20130603 (prerelease) (crosstool-NG 1.19.0)
Once you get this message you should be ok.
The only other thing to watch out for is if you got all of the libraries needed to compile your code.
e.g. for instance on Raspberry-pi (using Raspbian), some of the libs have to be manually imported from /lib and /usr/lib (put then in your LD_LIBRARY_PATH).
Sometimes the includes for gcc or g++ are not copied in the include directory of the toolchain (when using crosstool-ng, got the issue a couple of times), so you need to get the includes from your /usr/include directory.