Cannot cross-compile for arm with c++17 - c++

I am trying to cross-compile c++14/c++17 code for my raspberry pi. I am sure it worked on my old PC. However, when I try to compile it on my new pc, it returns me the following error.
$ arm-linux-gnueabihf-g++ main.cpp -std=c++17
arm-linux-gnueabihf-g++: error: unrecognized command line option ‘-std=c++17’
I thought it is the compiler issue, the version of the compiler I am using is:
$ arm-linux-gnueabihf-g++ --version
arm-linux-gnueabihf-g++ (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)
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.
I try to get the newest compiler with
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross binutils-arm-linux-gnueabi libncurses5-dev build-essential bison flex libssl-dev bc
Yet, the version is still the same, which can only compile c++11.
How can I update the arm-linux-gnueabi-g++ compiler?? I am pretty sure there is a compiler that works since I used it before, but not sure how I get it.

I found the easiest way to solve this issue is to directly install the newest cross-compiler
sudo apt-get install g++-9-arm-linux-gnueabihf
and use the compiler as (just an example of using c++17)
arm-linux-gnueabihf-g++-9 main.cpp -std=c++17

Related

How to configure g++ as the default compiler in Mac OS (M1)

So, I wanted to use some header files native to GNU C++:
#include <ext/pb_ds/assoc_container.hpp>
#include <ext/pb_ds/tree_policy.hpp>
I read that in MacOS, gcc and g++ are both linked to clang. So, we had to install the gcc using homebrew and use that.
But after installing gcc using homebrew. When I run
g++ --version
I get
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
But running g++-12 --version I get:
g++-12 (Homebrew GCC 12.2.0) 12.2.0
Copyright (C) 2022 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.
My VSCode runs g++ (Apple One) to compile C/C++ files. For the goal I wanted to accomplish at the start, I read that we need to have the g++ (installed using homebrew) do the compiling.
So, I ran the following commands:
cd /opt/homebrew/bin
ls -s g++-12 g++
But now, even when I compile the following code:
#include <iostream>
int main()
{
std::cout << 1;
}
I get the following error:
In file included from /opt/homebrew/Cellar/gcc/12.2.0/include/c++/12/bits/postypes.h:40,
from /opt/homebrew/Cellar/gcc/12.2.0/include/c++/12/iosfwd:40,
from /opt/homebrew/Cellar/gcc/12.2.0/include/c++/12/ios:38,
from /opt/homebrew/Cellar/gcc/12.2.0/include/c++/12/ostream:38,
from /opt/homebrew/Cellar/gcc/12.2.0/include/c++/12/iostream:39,
from test.cpp:1:
/opt/homebrew/Cellar/gcc/12.2.0/include/c++/12/cwchar:44:10: fatal error: wchar.h: No such file or directory
44 | #include <wchar.h>
| ^~~~~~~~~
compilation terminated.
Now, removing the link using rm g++ reverts back to my original configuration. But that configuration can't run the headers I requested at the start. Is there any way to solve this?
Most of the above have mostly been taken from here. But I didn't find any solution. But, I have seen people using the same and getting successful.
EDIT:
I found a website where there was a solution. It was to compile not using g++. Rather use
g++-12 --sysroot=$(xcrun --show-sdk-path)
When I used this, it solved the problem. Can someone explain why this happened?
The header error likely indicates the g++ you installed via Homebrew may not be compatible with the Apple Xcode version installed in the macos system directories.
The solution is probably to reinstall one or both packages.
EDIT:
g++-12 --sysroot=$(xcrun --show-sdk-path) changes the search path for system header includes from the default (which was probably set when homebrew installed g++) to the one provided by the Xcode SDK currently installed.

Can't cross-compile gdb with MinGW

I'm trying to cross-compile gdb so I could debug my Windows version of program.
My host system is Arch Linux(5.13.4-arch1-1 to be exact).
I'm using MinGW from the official repositories.
$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 11.2.0
Copyright (C) 2021 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.
I downloaded the source for gdb from https://ftp.gnu.org/gnu/gdb/ (gdb-10.2.tar.gz).
I unpacked it, cd into dir and ran:
$ ./configure --host=i686-w64-mingw32
$ make
For long it compiled without any errors and then:
CXX source-cache.o
source-cache.c:37:10: fatal error: srchilite/sourcehighlight.h: No such file or directory
37 | #include <srchilite/sourcehighlight.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
And also although compiler already compiled gdbserver and other different programs, I can't run them.
Launching gdbserver.exe with wine gives:
$ wine gdbserver.exe
0024:err:module:import_dll Library libgcc_s_dw2-1.dll (which is needed by L"Z:\\home\\udalny\\.local\\build\\gdb\\gdb-10.2\\gdbserver\\gdbserver.exe") not found
0024:err:module:import_dll Library libstdc++-6.dll (which is needed by L"Z:\\home\\udalny\\.local\\build\\gdb\\gdb-10.2\\gdbserver\\gdbserver.exe") not found
0024:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\udalny\\.local\\build\\gdb\\gdb-10.2\\gdbserver\\gdbserver.exe" failed, status c0000135
Is it not statically linked?
Does anybody know how to fix it?
You can avoid the problem with the configure flag --disable-source-highlight if you can do without sourxe highlighting.

OS X Yosemite gcc unrecognized command line option 'mdll' after brew install gcc

I installed gcc using brew because I needed to install brew's Fortran package. It seems that the gcc package installed by brew install gcc does not support the mdll flag. How can I install the correct versions of Fortran and gcc?
$ which gcc
/usr/local/bin/gcc
$ gcc --version
gcc (GCC) 4.9.2 20141029 (prerelease)
Copyright (C) 2014 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.
$ gcc -mdll
gcc: error: unrecognized command line option ‘-mdll’
gcc: fatal error: no input files
compilation terminated.
According to the gcc(1) manpage:
-mdll
This option is available for Cygwin and MinGW targets. It
specifies that a DLL---a dynamic link library---is to be generated,
enabling the selection of the required runtime startup object and
entry point.
Since OS X isn't either Cygwin or MinGW, it's safe to assume that no version of GCC will enable it on OS X.
If you're trying to build a dynamically linked object ("shared object" in UNIX terminology), check out the -dynamic/-dynamiclib flags. They seem to be the rough equivalent on OS X.

which gcc am I using?

I am attempting to compile a package on my Mac laptop and my Mac Mini desktop. It compiles successfully on the laptop, but not the mini (gives the following error: gcc: error: unrecognized command line option '-Xarch_x86_64'). Both machines are running OS X Yosemite (10.10.2). On both machines, when I type
which gcc
I get:
gcc: aliased to nocorrect gcc
(I don't know what this means) When I type
echo $PATH
I get:
/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
This makes me think that if a gcc is found in /usr/local/bin, that's the one that will be my gcc. When I type
ls -l /usr/local/bin/gcc
I get:
/usr/local/bin/gcc -> /usr/local/bin/gcc-4.8
on both machines. However, when I type
gcc --version
on the Mini I get:
gcc (Homebrew gcc48 4.8.4) 4.8.4
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 on the laptop I get:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
Which is the version installed by XCode. (This is what I get on both machines from /usr/bin/gcc --version)
How is the laptop using gcc 4.2 when the first gcc in my path is a symlink to gcc 4.8, and how do I make the mini do the same?
The nocorrect prefix is a zsh construct that will inhibit spelling correction.
It looks like you may have installed a specific gcc version with homebrew on the Mac Mini and you're using the system compiler (or rather, the one installed with XCode command line tools) on the laptop.
If you don't want to use the gcc installed with homebrew, you can just do:
brew unlink gcc
That will make the symlink go away and you'll use the next compiler. Which is hopefully the one you want.
When which gcc returns something like gcc: aliased to nocorrect gcc, the way to get the actual path would be to unalias foo, like this:
$ unalias gcc
$ which gcc
/usr/bin/gcc
This will remove the alias for the current shell, and you'll have to open up a new terminal or re-alias it yourself.
If you'd rather not do that, then you can use bash to determine the where the command is coming from:
$ bash -c 'which gcc'
/usr/bin/gcc

gpuocelot llvm/Assembly/Parser.h: No such file or directory

I am using ubuntu 12.04
I have been trying to install gpuocelot for a few day now.
I recently installed llvm from the svn using
svn co http://llvm.org/svn/llvm­project/llvm/trunk llvm
./configure ­­enable­optimized
sudo make
sudo make install
But to do this I had to update gcc to 4.7 which i had also done
Now when i run sudo ./build.py --install
I keep on getting the following error
ocelot/ocelot/ir/implementation/ExternalFunctionSet.cpp:28:34: fatal error: llvm/Assembly/Parser.h: No such file or directory
The following outputs might be of help
z
aid#zaid-lappy:~/gpuocelot$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2013 NVIDIA Corporation
Built on Wed_Jul_17_18:36:13_PDT_2013
Cuda compilation tools, release 5.5, V5.5.0
zaid#zaid-lappy:~/gpuocelot$ gcc --version
gcc (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
Copyright (C) 2012 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.
zaid#zaid-lappy:~/gpuocelot$ g++ --version
g++ (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
Copyright (C) 2012 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.
zaid#zaid-lappy:~$ echo $PATH
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/l/checkout/gpuocelot/ocelot/build_local/lib:/usr/local/cuda-5.5/bin
echo $LD_LIBRARY_PATH
/usr/local/cuda-5.5/lib64:
echo $LIBRARY_PATH returns blank
The LLVM C++ API, including the very existence and location of headers, is very unstable. This is why projects usually align themselves to some official release of LLVM, and I'm sure GPUOcelot follows the same pattern.
In top-of-tree LLVM, the header llvm/Assembler/Parse.h doesn't exist, which is why you can't find it. You should compile & link GPUOcelot vs. the LLVM version it supports officially. If GPUOcelot tries to follow the top-of-tree of LLVM, at least there should be a "known good revision" with which it works.