Missing include "bits/c++config.h" when cross compiling 64 bit program on 32 bit in Ubuntu

Question

I am running the 32bit version of Ubuntu 10.10 and trying to cross compile to a 64 bit target. Based on my research, I have installed the g++-multilib package.

The program is a very simple hello world:

#include <iostream>

int main( int argc, char** argv )
{
  std::cout << "hello world" << std::endl;
  return 0;
}

Compile:

g++ -m64 main.cpp

Error:

In file included from main.cpp:1:
/usr/include/c++/4.4/iostream:39: fatal error: bits/c++config.h: No such file or directory
compilation terminated.

I have found a c++config.h file but they reside under the i486-linux-gnu and i686-linux-gnu directories in /usr/include/c++/4.4/ There is not c++config.h in /usr/include/c++/bits.

Any ideas on what I am missing? Compiling without the -m64 flag works fine (a.out is created and runs correctly).

Edit Thanks to the hint from @nightcracker, I did a little more investigation into the include structure on the 32 and 64 bit systems. I have added an answer below that "fixes" the problem temporarily but I think it will break on the next update. Basically, I am missing a directory called /usr/include/c++/4.4/i686-linux-gnu/64 that should contain a subdirectory called bits that has the missing include file. Any idea what package should be taking care of this?

Highflown

Wow... I had this problem too. GCC 4.8 on a ARMv7-a CubieTruck (Cortex-A7) running Ubuntu. The bizarre thing (to me) is, Anthony's answer fixed it. Whatever... – Yttrium

Answer 1

Adding this answer partially because it fixed my problem of the same issue and so I can bookmark this question myself.

I was able to fix it by doing the following:

sudo apt-get install gcc-multilib g++-multilib

If you've installed a version of gcc / g++ that doesn't ship by default (such as g++-4.8 on lucid) you'll want to match the version as well:

sudo apt-get install gcc-4.8-multilib g++-4.8-multilib

Cambric

Make sure to match the versions of gcc and g++ installed on your system. On Ubuntu 14.04 I had gcc-4.8 and g++-4.8 installed, so I installed gcc-4.8-multilib and g++-4.8-multilib instead. – Monaco

This solved my problem when compiling with -m32 on a 64-bit machine. Thanks – Pokeberry

Thanks for the pointer, but sudo apt-get install gcc-multilib g++-multilib seems better (it resolves to your gcc version automatically). – Phira

^maybe not! @Zoltan's suggestion worked for me though. Anthony Sottile, maybe you should incorporate Zoltan's comment in your answer? – Mast

@Mast feel free to suggest an edit, when I initially posted it I matched the version asked in the question, it has since changed from other's edits – Cambric

This also happens on windows which do not happen to have apt-get. – Wolcott

@TomášZato the question says "Ubuntu" -- perhaps ask a new one for windows? – Cambric

Works for me on Utuntu 16.04 x64 version, when try to compile with -m32 flag. Before bits/c++config.h not found, sys/cdefs.h also not found, which is resolved by install libc6-dev-i386 package. – Depose

Worked on Ubuntu 17.14. Thank you! – Persian

It is disappointing that the 32 bit gcc/g++ compiler is not included complete. You get smaller, faster programs for your 4 bit system with 32 bit compile when you have no data structures or stack growth > 4GB. – Thera

Answer 2

Did you try adding -I/usr/include/c++/4.4/i486-linux-gnu or -I/usr/include/c++/4.4/i686-linux-gnu?

Godhead

That does indeed work. Any idea on why I would need to do this for only 64 bit? I am trying to set this machine up to help with distributed 64 bit builds and want to avoid too much customization. – Highflown

I am sorry, I have no idea, I just posed a quick hacky working solution :) – Godhead

simply because "bits/c++config.h" resides there :) – Petropavlovsk

Answer 3

While compiling in RHEL 6.2 (x86_64), I installed both 32bit and 64bit libstdc++-dev packages, but I had the "c++config.h no such file or directory" problem.

Resolution:

The directory /usr/include/c++/4.4.6/x86_64-redhat-linux was missing.

I did the following:

cd /usr/include/c++/4.4.6/
mkdir x86_64-redhat-linux
cd x86_64-redhat-linux
ln -s ../i686-redhat-linux 32

I'm now able to compile 32bit binaries on a 64bit OS.

Guido

On OpenSUSE I did cd /usr/include/c++/4.6;ln -s x86_64-suse-linux i586-suse-linux – Sunbeam

Answer 4

Seems to be a typo error in that package of gcc. The solution:

mv /usr/include/c++/4.x/i486-linux-gnu /usr/include/c++/4.x/i686-linux-gnu/64

Forbis

Answer 5

On my 64 bit system I noticed that the following directory existed:

/usr/include/c++/4.4/x86_64-linux-gnu/32/bits

It would then make sense that on my 32 bit system that had been setup for 64bit cross compiling there should be a corresponding directory like:

/usr/include/c++/4.4/i686-linux-gnu/64/bits

I double checked and this directory did not exist. Running g++ with the verbose parameter showed that the compiler was actually looking for something in this location:

jesse@shalored:~/projects/test$ g++ -v -m64 main.cpp 
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --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.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 
COLLECT_GCC_OPTIONS='-v' '-m64' '-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc/i686-linux-gnu/4.4.5/cc1plus -quiet -v -imultilib 64 -D_GNU_SOURCE main.cpp -D_FORTIFY_SOURCE=2 -quiet -dumpbase main.cpp -m64 -mtune=generic -auxbase main -version -fstack-protector -o /tmp/ccMvIfFH.s
ignoring nonexistent directory "/usr/include/c++/4.4/i686-linux-gnu/64"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../i686-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.4
 /usr/include/c++/4.4/backward
 /usr/local/include
 /usr/lib/gcc/i686-linux-gnu/4.4.5/include
 /usr/lib/gcc/i686-linux-gnu/4.4.5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++ (Ubuntu/Linaro 4.4.4-14ubuntu5) version 4.4.5 (i686-linux-gnu)
    compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128197
Compiler executable checksum: 1fe36891f4a5f71e4a498e712867261c
In file included from main.cpp:1:
/usr/include/c++/4.4/iostream:39: fatal error: bits/c++config.h: No such file or directory
compilation terminated.

The error regarding the ignoring nonexistent directory was the clue. Unfortunately, I still don't know what package I need to install to have this directory show up so I just copied the /usr/include/c++/4.4/x86_64-linux-gnu/bits directory from my 64 bit machine to /usr/include/c++/4.4/i686-linux-gnu/64/bits on my 32 machine.

Now compiling with just the -m64 works correctly. The major drawback is that this is still not the correct way to do things and I am guessing the next time Update Manager installs and update to g++ things may break.

Highflown

Nice debugging technique! – Hedges

Answer 6

Basically It is used in HeapOverflows or other reversing type Problems i.e. If you want to change a 64 bit ELF to 32 bit ELF and it is showing error while converting.

You can simply run the commands

apt-get install gcc-multilib g++-multilib

which will update your libraries Packages upgraded:

The following additional packages will be installed: g++-8-multilib gcc-8-multilib lib32asan5 lib32atomic1 lib32gcc-8-dev lib32gomp1 lib32itm1 lib32mpx2 lib32quadmath0 lib32stdc++-8-dev lib32ubsan1 libc-dev-bin libc6 libc6-dbg libc6-dev libc6-dev-i386 libc6-dev-x32 libc6-i386 libc6-x32 libx32asan5 libx32atomic1 libx32gcc-8-dev libx32gcc1 libx32gomp1 libx32itm1 libx32quadmath0 libx32stdc++-8-dev libx32stdc++6 libx32ubsan1 Suggested packages: lib32stdc++6-8-dbg libx32stdc++6-8-dbg glibc-doc The following NEW packages will be installed: g++-8-multilib g++-multilib gcc-8-multilib gcc-multilib lib32asan5 lib32atomic1 lib32gcc-8-dev lib32gomp1 lib32itm1 lib32mpx2 lib32quadmath0 lib32stdc++-8-dev lib32ubsan1 libc6-dev-i386 libc6-dev-x32 libc6-x32 libx32asan5 libx32atomic1 libx32gcc-8-dev libx32gcc1 libx32gomp1 libx32itm1 libx32quadmath0 libx32stdc++-8-dev libx32stdc++6 libx32ubsan1

similar to this will be shown to your terminal

Bakken

On Debian 10 a number of packages that I want to keep would have been removed. The following packages will be REMOVED: g++-8-arm-linux-gnueabi g++-8-arm-linux-gnueabihf g++-arm-linux-gnueabi g++-arm-linux-gnueabihf gcc-8-aarch64-linux-gnu gcc-8-arm-linux-gnueabi gcc-8-arm-linux-gnueabihf gcc-aarch64-linux-gnu gcc-arm-linux-gnueabi gcc-arm-linux-gnueabihf – Carbylamine

Answer 7

This bug is fixed in "gcc-4.6".

https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/793411

Cathar

Answer 8

Ran into the same problem while cross-compiling on x86 machine for arm32, if you are cross-compiling then for arm then make sure you have installed the latest libstdc++ pkg.

sudo apt install libstdc++-10-dev-armhf-cross

Then you may run into another header error which is 'asm/errno.h' file not found. Just install gcc-multilib for this.

sudo apt install gcc-multilib

Boiling

Thank you. Same use case for me too. I also had to do a sudo apt install g++-multilib libstdc++-9-dev-armhf-cross – Marek

Answer 9

From my experience, sudo apt-get install gcc-multilib g++-multilib helps. But my another issue is that I FORGET to clean the directory so I still get the same error. It is the first time to use clang or cmake. So I just delete my original directory and re-compile and it works. Hope it helps someone like me.

Loose

Answer 10

In my case, it only has been a path issue. I reduced the path length of my source files and it worked...

Desperation

??? Please share an example. "path length of .. source files" really shouldn't ever be a problem. How is it that you had a src file path that was too long? – Hedges

Sorry, I'm not able to recreate the problem right now. It happened on a Windows system which may have (note: does not apply in all cases) a path limitation of 260 chars. – Desperation