Compiling a 32 application on 64 bit, without getting rid of GNU EABI for ARM

Question

I want to build a C++ program for 32 bit on my 64 bit 16.04.

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status

Linking using g++ fails searching for -lstdc++ says I should install libc6-i386 libc6-dev-i386 lib32gcc1 lib32stdc++6, which gives:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
lib32gcc1 is already the newest version (1:6.0.1-0ubuntu1).
lib32gcc1 set to manually installed.
libc6-dev-i386 is already the newest version (2.23-0ubuntu3).
libc6-dev-i386 set to manually installed.
libc6-i386 is already the newest version (2.23-0ubuntu3).
lib32stdc++6 is already the newest version (5.3.1-14ubuntu2.1).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

OK, good, now let's try the accepted answer: install g++-multilib (or gcc-multilib, the result is the same):

Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  binutils-arm-linux-gnueabi cpp-5-arm-linux-gnueabi cpp-arm-linux-gnueabi gcc-5-arm-linux-gnueabi-base
  gcc-5-cross-base libasan2-armel-cross libasan2-dbg-armel-cross libatomic1-armel-cross libatomic1-dbg-armel-cross
  libc6-armel-cross libc6-armhf-armel-cross libc6-armhf-cross libc6-dev-armel-cross libc6-dev-armhf-armel-cross
  libc6-dev-armhf-cross libgcc-5-dev-armel-cross libgcc1-armel-cross libgcc1-dbg-armel-cross libgomp1-armel-cross
  libgomp1-dbg-armel-cross libhfasan2-armel-cross libhfatomic1-armel-cross libhfgcc-5-dev-armel-cross
  libhfgcc1-armel-cross libhfgomp1-armel-cross libhfstdc++6-armel-cross libhfubsan0-armel-cross libstdc++6-armel-cross
  libubsan0-armel-cross libubsan0-dbg-armel-cross linux-libc-dev-armel-cross linux-libc-dev-armhf-cross
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  g++-5-multilib gcc-multilib lib32gcc1-dbg lib32stdc++-5-dev lib32stdc++6-5-dbg libx32gcc1-dbg libx32stdc++-5-dev
  libx32stdc++6-5-dbg
The following packages will be REMOVED:
  gcc-5-arm-linux-gnueabi gcc-5-multilib-arm-linux-gnueabi gcc-arm-linux-gnueabi
The following NEW packages will be installed:
  g++-5-multilib g++-multilib gcc-multilib lib32gcc1-dbg lib32stdc++-5-dev lib32stdc++6-5-dbg libx32gcc1-dbg
  libx32stdc++-5-dev libx32stdc++6-5-dbg
0 upgraded, 9 newly installed, 3 to remove and 1 not upgraded.
Need to get 14.7 MB of archives.
After this operation, 82.5 MB of additional disk space will be used.

I like being able to build GNU C11 on my laptop and have it run on my phone (see here), which is possible with arm-linux-gnueabi-gcc, so I don't want to get rid of that. (I am uninterested in doing the same for C++11).

The new packages that gcc-multilib will install seem to be C++-only, but it will remove C compilers and binutils for ARM and other platforms, which I want to keep.

Can I have compilers for 32-bit GNU C++11 and ARM GNU C11 simultaneously?

Answer 1

The package installation of other architecture compilers puts them into a system area. The executables are uniquely named, but the package is too "helpful" and thinks you really need a short name link (like gcc) to point to them, and whoa, another package already uses that link, gotta delete it for you. This might be fine in a virtual machine, dedicated to one sort of toolchain, but is not desirable under normal circumstances.

You can unpack the package yourself, and copy the executables into /usr/bin if you want. If multiple users are using the compiler, that would be way to do it, but as a single user, I never bothered. I just unpacked locally in my own directory, and set enviromment variables and local links as needed. The drawback is not getting package updates as they come out. The benefit is selecting when you want to change compiler version, test the new installation against the old one, and when you have validated the new package meets your needs, you can switch over. You cannot do that by putting the new version into the standard system area because the new version names are not different from the old ones.

example of a local toolchain setup script:

$ cat crossexp
MY_ARM_BASE=${HOME}/dev/toolchain/arm-2008q3
C_INCLUDE_PATH=${MY_ARM_BASE}/lib/gcc/arm-none-linux-gnueabi/4.3.2/include:${MY_ARM_BASE}/lib/gcc/arm-none-linux-gnueabi/4.3.2/include-fixed
LIBRARY_PATH=${MY_ARM_BASE}/arm-none-linux-gnueabi/libc/lib:${MY_ARM_BASE}/arm-none-linux-gnueabi/libc/usr/lib
CPLUS_INCLUDE_PATH=${MY_ARM_BASE}/arm-none-linux-gnueabi/include/c++/4.3.2
#OBJC_INCLUDE_PATH
COMPILER_PATH=${MY_ARM_BASE}/bin
#LD_RUN_PATH
#GPROF_PATH
#######
CC=${COMPILER_PATH}/gcc
CXX=${COMPILER_PATH}/g++
RANLIB=${COMPILER_PATH}/ranlib
STRIP=${COMPILER_PATH}/strip
export C_INCLUDE_PATH LIBRARY_PATH CPLUS_INCLUDE_PATH OMPILER_PATH
export CC CXX RANLIB STRIP

The executables are in ${COMPILER_PATH} with names like
arm-none-linux-gnueabi-gcc so you can add a link to that directory with the short name:

ln -s arm-none-linux-gnueabi-gcc gcc

Just a convenience for you, most makefiles run off the definitions like the ones shown above, and the full name could just as easily have been uses there instead of a short name.

Have a setup script for each architecture, and you can have a setup scripts for different versions of a compiler within an architecture.