How to install a native gcc toolchain onto the target platform?

Unturned3 · 12-03-2018, 02:30 AM

Hello,
I built myself a cross toolchain targeting the generic x86_64 platform with musl-libc & gcc. So far, it worked quite well and I managed to install musl and busybox onto the target platform. Now I'm trying to install a gcc toolchain that will run natively on the target. How can I use my existing cross-toolchain to install a toolchain onto the target?

Currently, I have a folder named "targetfs" where all the cross-compiled libraries and headers are (this is basically the root file system that gets stuffed into QEMU). How can I install a toolchain into this targetfs folder?

Thanks for helping.

hazel · 12-03-2018, 09:56 AM

The way Linux From Scratch/Cross Linux From Scratch does it is to use the cross-compiled gcc, binutils and libc to build fully native versions. I notice that you don't mention binutils but you will definitely need a cross-compiled version of that package.

After that, the cross-versions aren't used any more. You use the second-stage native versions to build a more complete toolchain, then use those tools to build your final system.

Unturned3 · 12-04-2018, 12:22 AM

Hello,
Yes I forgot to mention binutils. I built my toolchain by following the CLFS book (but with binutils-2.30, gcc-7.3.0, and musl-1.1.20 instead) and this is how I configured gcc when trying to install it onto the targetfs with my cross toolchain:

Code:

../configure --prefix=$CLFS/targetfs/usr \
--host=$CLFS_TARGET --enable-languages=c,c++ \
--disable-multilib --disable-bootstrap \
--disable-libsanitizer

(I had to disable libsanitizer because it doesn't work with musl-libc)

When I only enabled the C language, the C compiler installed on the targetfs ran without problems. However, the problem is that when I add c++ compiler support with "--enable-languages=c,c++", the build process fails with this error message:

Code:

ctype_members.cc: In constructor 'std::ctype_byname<char>::ctype_byname(const char*, std::size_t)':
ctype_members.cc:50:44: error: cannot convert 'const short unsigned int*' to 'const mask*' {aka 'const unsigned int*'} in assignment
  this->_M_table = this->_M_c_locale_ctype->__ctype_b;
                                            ^~~~~~~~~
make[5]: *** [Makefile:562: ctype_members.lo] Error 1

I mean, errors such as "undefined references" are understandable if my toolchain are missing files/components, but how can a conversion error happen? Does the language rules allow or disallow this syntax? Is it possible that my toolchain is missing some components that causes it to disallow this syntax?

Thanks!

hazel · 12-04-2018, 11:11 AM

Did you build the libstdc++ library? It's in the gcc sources. I think the second build of gcc needs it.
http://www.linuxfromscratch.org/lfs/...libstdc++.html

Unturned3 · 12-04-2018, 07:29 PM

Hello,
I didn't explicitly build the libstdc++ library (as instructed around the "pass 2" stage in the LFS book), because I built the musl toolchain following the CLFS book. The CLFS book said that if I needed a c++ compiler, I just need to add "--enable-language=c,c++" to the configure options. I wondered why I didn't need to explicitly build libstdc++ before that, and I found this blog post that explained it as follows:

Quote:

You may wonder why we didn't have to build a libstdc++ between the first and second pass, like the libc.
The source code for the libstdc++ comes with the G++ compiler and is built automatically like libgcc.

I checked inside the "lib" and "include" folders inside my cross toolchain's sysroot directory and all the libstdc++ header files & library files are present. I can also use the g++ compiler from my cross toolchain to build c++ programs that runs with no problem. However I just can't use this cross toolchain to build & install libstdc++ onto my target system. It generates that "conversion" error I posted previously.

Thanks!

hazel · 12-05-2018, 06:36 AM

I think it would have to depend on how you built the cross-gcc. In LFS, this has practically all its libraries including stdlibc++ disabled. Then you build a separate stdlibc++ after libc and before rebuilding gcc. I'm sure there's a good reason why it is done this way.

I know there are parts of gcc that only gcc can build. Perhaps there are parts of gcc that only a stdlibc++-enabled gcc can build. I can't think of anything else; I've come to the end of my knowledge. The LFS forum might be the best place to pursue the question .