I recently installed gcc 4.9.2 and found a problem when linking with libs.
The output for search path:
install: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/
programs: =/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/
libraries: =/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/lib/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/lib/../lib64/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/:/lib/x86_64-unknown-linux-gnu/4.9.2/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-unknown-linux-gnu/4.9.2/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/lib/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../:/lib/:/usr/lib/
Really, the problematic thing is this:
/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/
I need to change the order of these two libs(so that lib64 has higher search priority), because both dirs have the libstdc++.so.6, and I need to use the one in lib64 folder.
How do I do it?
Please don't:
1, suggest that I change LD_LIBRARY_PATH to explicitly include libstdc++.so.6 as I'm sure there are other things in x86_64-linux-gnu folder that are older versions of that in the lib64 folder - I upgraded g++ from an older version.
2, suggest that I explicitly include that lib64/libstdc++.so.6 in the g++ -L option.
Thanks a lot.
/************************EDIT FOR MORE INFO************************/
Upon the request below, here're some more details about configuration and installation(I downloaded 4.9.2 source from gcc.gnu.org, extracted it and started in the 4.9.2 top level folder):
mkdir ../gcc-build &&
cd ../gcc-build &&
../gcc-4.9.2/configure \
--prefix=/usr \
--libdir=/usr/lib \
--enable-shared \
--enable-threads=posix \
--enable-__cxa_atexit \
--disable-multilib \
--with-system-zlib \
--enable-languages=c,c++ &&
make
You could have a new (or modify the existing) GCC specs file, documentation is here.
AFAIK, the specs file is in your "install" dir, so for you would be in /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/specs (which you could create if it does not exist).
AFAIK there is some built-in default, but you could configure your system to have an explicit one.
Read also about the debugging options of GCC. You may want to use -dumpspecs to get the built-in default spec.
Details may be highly specific to your system, especially if you compiled GCC from its source code.
I am not familiar enough with specs files to give a reliable solution for your particular issue. You might ask on gcc-help#gcc.gnu.org for details.
NB: I would tend to believe that configuring a gcc with --prefix=/usr (and not a non-system prefix like the default --prefix=/usr/local/ or some --prefix=/opt/ etc...) is a mistake (or at least use also --program-suffix=-4.9). You are likely to mix up your gcc with the system gcc; If you want to replace your system gcc (which is probably dangerous) you should configure your new gcc with the same arguments as your system gcc had. Notice that /usr/bin/gcc -v tells you how was your system gcc configured (to be done before overwriting it).
When compiling a recent GCC 4.9 on some older system I generally would recommend to configure it with --prefix=/usr/local/ and --program-suffix=-4.9 then add /usr/local/bin/ to your $PATH, and use make CC=gcc-4.9 CXX=g++-4.9 for building programs with it.
Related
I'm trying to compile libjpeg on windows, which uses libtool as part of it's process.
Whenever i tried to make install, libtool would complain about absolute paths, despise the fact that I was giving it an absolute path
$ ../configure --enable-shared --enable-static --prefix D:/hernan/programacion/libjpeg/install
$ make install
(bunch of unrelated descriptions)
./libtool --mode=install /bin/install -c libjpeg.la D:/hernan/programacion/libjpeg/install/lib/libjpeg.la
libtool: install: `D:/hernan/programacion/libjpeg/install/lib' must be an absolute directory name
Try `libtool --help --mode=install' for more information.
I'm using mingw shell, since ./configure never works on cmd
Ok, so the solution for this is rather silly.
While the link and compile modes interpret correctly my path, the install mode that depends on libtool doesn't. You have to change the driver part of the prefix erasing the : and encasing it between /
So in my case it ended up being
$ ../configure --enable-static --enable-shared --prefix /d/hernan/programacion/libjpeg/install
I downloaded the toolchain “gcc-arm-none-eabi-6-2017-q2-update-win32-sha1.exe” (Windows) from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads and installed it on my Windows 10 PC.
The installation folder contains a release.txt in “../share/doc/gcc-arm-none-eabi/” which tells:
This release includes the following items:
newlib and newlib-nano :
git://sourceware.org/git/newlib-cygwin.git commit 0d79b021a4ec4e6b9aa1a9f6db0e29a137005ce7
And also the readme.txt in “../share/doc/gcc-arm-none-eabi/” contains:
C Libraries usage *
This toolchain is released with two prebuilt C libraries based on
newlib: one is the standard newlib (libc.a) and the other is
newlib-nano (libc_nano.a) for code size.
Now I want exactly rebuild all the libc.a and libc_nano.a contained in “../arm-none-eabi/lib/thumb”
At the moment I can build on Ubuntu with “gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2”
$ # Downloaded newlib-cygwin (with corresponding hash) into folder newlib-cygwin
$ mkdir build
$ cd build
$ ../newlib-cygwin/configure --target=arm-none-eabi --disable-newlib-supplied-syscalls
$ make
How do I have to configure the newlib to build the exact copies of libc.a and for libc_nano.a contained in gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2?
$ # Downloaded newlib-cygwin (with corresponding hash) into folder newlib-cygwin
$ mkdir build
$ cd build
$ ../newlib-cygwin/configure --target=arm-none-eabi --???
$ make
If i understand you correctly, a more detailed question is:
What configure options did 'GNU Arm Embedded Toolchain' developers used when building newlib libraries shipped in gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 archive?
These ones for newlib:
--target=arm-none-eabi --enable-newlib-io-long-long --enable-newlib-register-fini --enable-newlib-retargetable-locking --disable-newlib-supplied-syscalls --disable-nls
And these ones for newlib-nano:
--target=arm-none-eabi --enable-newlib-reent-small --disable-newlib-fvwrite-in-streamio --disable-newlib-fseek-optimization --disable-newlib-wide-orient --enable-newlib-nano-malloc --disable-newlib-unbuf-stream-opt --enable-lite-exit --enable-newlib-global-atexit --enable-newlib-nano-formatted-io --disable-nls
How I got it? Let's walk through the process:
These packages are build on launchpad, where from you find all the builds that took place on lanuchpad. I picked gcc-arm-none-eabi 6-2017q2-1 from 2017-10-24. There i can find the buildlog. I grepped the buildlog with | grep "^+ " | grep "configure " | grep 'src/newlib' and i was left with:
+ /<<PKGBUILDDIR>>/src/newlib/configure --target=arm-none-eabi --prefix=/<<PKGBUILDDIR>>/install-native --infodir=/<<PKGBUILDDIR>>/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/<<PKGBUILDDIR>>/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/<<PKGBUILDDIR>>/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/<<PKGBUILDDIR>>/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-newlib-io-long-long --enable-newlib-register-fini --enable-newlib-retargetable-locking --disable-newlib-supplied-syscalls --disable-nls
+ /<<PKGBUILDDIR>>/src/newlib/configure --target=arm-none-eabi --prefix=/<<PKGBUILDDIR>>/build-native/target-libs --disable-newlib-supplied-syscalls --enable-newlib-reent-small --disable-newlib-fvwrite-in-streamio --disable-newlib-fseek-optimization --disable-newlib-wide-orient --enable-newlib-nano-malloc --disable-newlib-unbuf-stream-opt --enable-lite-exit --enable-newlib-global-atexit --enable-newlib-nano-formatted-io --disable-nls
A bit of Sherlock Holmes and i deduced that the second line is newlib configured to build as newlib-nano (--enable-newlib-reent-small), the first is newlib configured to build as full newlib.
To answer your topic question, to recompile newlib and newlib-nano the same way pass the options I have posted above to newlib ./configure script.
Hints about how the compiler was configured are found in:
$COMPILER_PATH/arm-none-eabi/include/newlib.h
$COMPILER_PATH/arm-none-eabi/include/newlib-nano/newlib.h
The #defines there have a close correspondence to the options that were passed to 'configure', when newlib was built.
I figured it would be useful to give the default configuration of the ARM built newlib/newlib-nano as of 2023 (for GCC 10):
For Newlib:
--enable-newlib-io-long-long
--enable-newlib-io-c99-formats
--enable-newlib-reent-check-verify
--enable-newlib-register-fini
--enable-newlib-retargetable-locking
--disable-newlib-supplied-syscalls
--disable-nls
For Newlib-nano:
--disable-newlib-supplied-syscalls
--enable-newlib-reent-check-verify
--enable-newlib-reent-small
--enable-newlib-retargetable-locking
--disable-newlib-fvwrite-in-streamio
--disable-newlib-fseek-optimization
--disable-newlib-wide-orient
--enable-newlib-nano-malloc
--disable-newlib-unbuf-stream-opt
--enable-lite-exit
--enable-newlib-global-atexit
--enable-newlib-nano-formatted-io
--disable-nls
Ref: https://community.arm.com/support-forums/f/compilers-and-libraries-forum/53310/gcc-arm-none-eabi-what-were-the-newlib-compilation-options
I'm trying to build gcc-5.3 and binutils-2.26. I've done it like this:
mkdir gcc; cd gcc
wget http://path/to/gcc-5.3.0.tar.bz2
wget http://path/to/binutils-2.26.tar.bz2
tar xf gcc-5.3.0.tar.bz2
tar xf binutils-2.26.tar.bz2
cd gcc-5.3.0
contrib/download_prerequisites
for file in ../binutils-2.26/*; do ln -s "${file}"; done
cd ..
mkdir build
mkdir dist
cd build
../gcc-5.3.0/configure --prefix=/home/teamcity/gcc/dist --disable-multilib --with-system-zlib --enable-languages=c,c++,fortran --program-suffix=-mine
make
This appears to build the first stage executables okay; prev-gas, prev-gcc, prev-ld are all present with plausible-looking executables in them. But the next stage fails:
Configuring stage 2 in ./intl
configure: loading cache ./config.cache
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for x86_64-unknown-linux-gnu-gcc... /home/teamcity/gcc/build/./prev-gcc/xgcc -B/home/teamcity/gcc/build/./prev-gcc/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/lib/ -isystem /home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/include -isystem /home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/sys-include -L/home/teamcity/gcc/build/./ld
checking for C compiler default output file name...
configure: error: in `/home/teamcity/gcc/build/intl':
configure: error: C compiler cannot create executables
See `config.log' for more details.
The relevant bit of config.log appears to be this:
configure:2978: checking for C compiler default output file name
configure:3000: /home/teamcity/gcc/build/./prev-gcc/xgcc -B/home/teamcity/gcc/build/./prev-gcc/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unkn
own-linux-gnu/bin/ -B/home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/lib/ -isystem /home/teamcity/gcc/dist/x86_64-unknown-linux-gnu/include -isystem /home/teamcity/gcc/dist/x86_64-unknown-l
inux-gnu/sys-include -L/home/teamcity/gcc/build/./ld -g -O2 -gtoggle -static-libstdc++ -static-libgcc conftest.c >&5
/home/teamcity/gcc/build/./prev-gcc/as: 106: exec: /home/teamcity/gcc/build/./gas/as-new: not found
This looks like prev-gcc's as is expecting to find gas/as-new, when actually it's prev-gas/as-new.
Is there some workaround for this? Is it safe to just ln -s prev-gas gas? I'd sort of expect that to cause problems later on. Is it not possible to build these two versions of gcc and binutils together?
This is my edited answer after trying it on my own on an Ubuntu 14.04 Azure VM.
The following approach worked for me:
Build and install binutils 2.26; for the purposes of this discussion,
let's say it's installed in /opt/gcc-5.3.0.
Configure gcc-5.3.0 in a build directory using /root/objdir/../gcc-5.3.0/configure --prefix=/opt/gcc-5.3.0
--enable-languages=c,c++ --disable-multilib --with-ld=/opt/gcc-5.3.0/bin/ld --with-as=/opt/gcc-5.3.0/bin/as assuming gcc-5.3.0 and the build directory, objdir, are at the same
level.
Do make followed by make install in the objdir build directory.
To verify that the ld used by the newly-built gcc is the one from the new binutils:
/opt/gcc-5.3.0/bin/gcc -print-prog-name=ld
The output should be, in this example:
/opt/gcc-5.3.0/bin/ld
Another test: rename the system ld, in my case /usr/bin/ld; the newly-built gcc should still work.
Of course, this applies to both ld and as.
Setting AS and LD environment variables to point to the newly-built binaries from the binutils package did not work: the -print-prog-name=... still showed default tools, and removing/renaming the default tools caused gcc to fail.
Thus the best way of accomplishing this is to build binutils first and then use the --with-ld and --with-as options to configure. If you also want to ensure that the newly-built binutils are used to build GCC, you may want to put them in the PATH before the system-provided tools, or you can even rename the system-provided tools to keep them out of the picture.
Thank you for checking with another mailing list to verify that building GCC and binutils together doesn't work unless they are pulled from the source control, I guess that option is not applicable when using downloaded tarballs. Overall this was an interesting exercise.
I downloaded and built gcc 4.8.1 on my desktop, running 64-bit Ubuntu 12.04. I built it out of source, like the docs recommend, and with the commands
../../gcc-4.8.1/configure --prefix=$HOME --program-suffix=-4.8
make
make -k check
make install
It seemed to pass all the tests, and I installed everything into my home directory w/ the suffix -4.8 to distinguish from the system gcc, which is version 4.6.3.
Unfortunately when I compile c++ programs using g++-4.8 it links to the system libc and libstdc++ rather than the newer ones compiled from gcc-4.8.1. I downloaded and built gcc 4.8 because I wanted to play around with the new C++11 features in the standard library, so this behaviour is definitely not what I wanted. What can I do to get gcc-4.8 to automatically link to the standard libraries that came with it rather than the system standard libraries?
When you link with your own gcc you need to add an extra run-time linker search path(s) with -Wl,-rpath,$(PREFIX)/lib64 so that at run-time it finds the shared libraries corresponding to your gcc.
I normally create a wrapper named gcc and g++ in the same directory as gcc-4.8 and g++-4.8 which I invoke instead of gcc-4.8 and g++-4.8, as prescribed in Dynamic linker is unable to find GCC libraries:
#!/bin/bash
exec ${0}SUFFIX -Wl,-rpath,PREFIX/lib64 "$#"
When installing SUFFIX and PREFIX should be replaced with what was passed to configure:
cd ${PREFIX}/bin && rm -f gcc g++ c++ gfortran
sed -e 's#PREFIX#${PREFIX}#g' -e 's#SUFFIX#${SUFFIX}#g' gcc-wrapper.sh > ${PREFIX}/bin/gcc
chmod +x ${PREFIX}/bin/gcc
cd ${PREFIX}/bin && ln gcc g++ && ln gcc c++ && ln gcc gfortran
(gcc-wrapper.sh is that bash snippet).
The above solution does not work with some versions of libtool because g++ -Wl,... -v assumes linking mode and fails with an error.
A better solution is to use specs file. Once gcc/g++ is built, invoke the following command to make gcc/g++ add -rpath to the linker command line (replace ${PREFIX}/lib64 as necessary):
g++ -dumpspecs | awk '/^\*link:/ { print; getline; print "-rpath=${PREFIX}/lib64", $0; next } { print }' > $(dirname $(g++ -print-libgcc-file-name))/specs
I just had the same problem when building gcc-4.8.2. I don't have root access on that machine and therefore need to install to my home directory. It took several attempts before I figured out the magic required to get this to work so I will reproduce it here so other people will have an easier time. These are the commands that I used to configure gcc:
prefix=/user/grc/packages
export LDFLAGS=-Wl,-rpath,$prefix/lib
export LD_RUN_PATH=$prefix/lib
export LD_LIBRARY_PATH=$prefix/lib
../../src/gmp-4.3.2/configure --prefix=$prefix
../../src/mpfr-2.4.2/configure --prefix=$prefix
../../src/mpc-0.8.1/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix
../../src/gcc-4.8.2/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix --with-mpc=$prefix --enable-languages=c,c++
That got me a working binary but any program I built with that version of g++ wouldn't run correctly unless I built it with the -Wl,-rpath,$prefix/lib64 option. It is possible to get g++ to automatically add that option by providing a specs file. If you run
strace g++ 2>&1 | grep specs
you can see which directories it checks for a specs file. In my case it was $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/specs so I ran g++ -dumpspecs to create a new specs file:
cd $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
$prefix/bin/g++ -dumpspecs > xx
mv xx specs
and then edited that file to provide the -rpath option. Search for the lines like this:
*link_libgcc:
%D
and edit to add the rpath option:
*link_libgcc:
%D -rpath /user/grc/packages/lib/%M
The %M expands to either ../lib or ../lib64 depending on whether you are building a 32-bit or a 64-bit executable.
Note that when I tried this same trick on an older gcc-4.7 build it didn't work because it didn't expand the %M. For older versions you can remove the %M and just hardcode lib or lib64 but that is only a viable solution if you only ever build 32-bit executables (with lib) or only ever build 64-bit executables (with lib64).
gcc -print-search-dirs will tell you where your compiler is looking for runtime libraries, etc. You can override this with the -B<prefix> option.
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.