Expected errors while building a cross compiler

[~]

I have tried to build a cross compiler under Slackware.

I have been able to build the latest Binutils and GCC (by downloading its prerequisites).

The only error I'm getting is when trying to compile LibGCC. It says that it "cannot compute the suffix for object files".

The rest of things seem to be OK and I seem to be able to use GCC/AS/LD for i686-elf.

However I think that there would be no libgcc available although it wouldn't matter if writing a kernel and reimplementing the C library.

But is that error really expected ("cannot compute the suffix for object files") or is there something else to do? It seems to fail while compiling a short test program from the GCC build sources which has some defines and an empty int main() returning 0.

[Octocontrabass]

However I think that there would be no libgcc available although it wouldn't matter if writing a kernel and reimplementing the C library.

You cannot use GCC without libgcc. No exceptions.

What versions of GCC and binutils did you build? What steps did you follow to build them?

[~]

I used Topologilinux 7.0.1. It has GCC 4.x.
Maybe I should use a newer Linux, but it seems to be something else.
Compiled as root but compiled only for me, not into the main system directories.

Added these directives:

Code: Select all

export PREFIX="$HOME/opt/cross"
export TARGET=i686-elf
export PATH="$PREFIX/bin:$PATH"

Downloaded Binutils 2.27.
Compiled from build-binutils directory.

Downloaded GCC 6.20.
Ran "contrib/download_prerequisites" from the GCC source directory.
Compiled from build-gcc directory.
Ran "make all-target-libgcc" and got the "cannot compute the prefix for object files" error.


Now I have as, ld, gcc, g++ and other associated binaries prefixed with "i686-elf-", and libraries/stuff prefixed.

This is the point where I'm at and I don't know if this error is expected given it's a cross compiler, supposedly trying to build normal test programs from the sources' test suite.

[Octocontrabass]

I used Topologilinux 7.0.1. It has GCC 4.x.

That's pretty old. You might need to bootstrap a newer version of GCC first, or use an environment that's less than 7 years old (e.g. MSYS2).

This is the point where I'm at and I don't know if this error is expected given it's a cross compiler, supposedly trying to build normal test programs from the sources' test suite.

You definitely shouldn't get any errors while computing the suffix for object files. What does config.log have to say about it?

[~]

You can see the full log here (it fails apparently for not having a static LibStdc++ in program "conftest.cpp"):
http://pastebin.com/gsgxHYMF

This seems to be the part where the error occurs:

Code: Select all

configure:5135: g++ -o conftest -g -O2   -static-libstdc++ -static-libgcc conftest.cpp  >&5
g++: unrecognized option '-static-libstdc++'
conftest.cpp:11:2: error: #error -static-libstdc++ not implemented
configure:5135: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
| 
| #if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 5)
| #error -static-libstdc++ not implemented
| #endif
| int main() {}

[Octocontrabass]

Are you sure you're looking at the right log? I don't see the error message you were talking about earlier, and it doesn't look like there were any problems.

[~]

The error seems to be about an "unrecognized -static-libstdc++ option", starting at lines 166-167 here:

http://pastebin.com/gsgxHYMF


Everything seems to be OK just looking at the binaries and running them with no arguments which produces a "fatal error: no input files", but I don't know if this single error doesn't matter and whether it's expected for such a raw cross compiler (the next install commands might make no sense if the libgcc command stage fails).

Code: Select all

166.
configure:5135: g++ -o conftest -g -O2   -static-libstdc++ -static-libgcc conftest.cpp  >&5
167.
g++: unrecognized option '-static-libstdc++'
168.
conftest.cpp:11:2: error: #error -static-libstdc++ not implemented

[Octocontrabass]

The error you're focusing on in that log is normal and expected.

Where's the log with the error you were talking about earlier? That's the log we need to see if you're having trouble.

[~]

That's all the log.

But there's a log for the "libgcc" subdirectory (containing only config.cache -empty-, config.log -below-, multilib.out -contains only the 2 characters ".;"-):
http://pastebin.com/veKiC5h6

I said libgcc because that's what the command is about:
make all-target-libgcc

The console then shows it at the end and terminates with an error:

Code: Select all

checking for suffix of object files... configure: error: in `/root/Desktop/src/build-gcc/i686-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make: *** [configure-target-libgcc] Error 1
root@slack:~/Desktop/src/build-gcc# kedit config.log &
[6] 11973
root@slack:~/Desktop/src/build-gcc#

"/root/Desktop/src/build-gcc/i686-elf/libgcc"


Then when trying to install libgcc this happens:

Code: Select all

root@slack:~/Desktop/src/build-gcc# make install-target-libgcc
/bin/sh ../gcc-6.2.0/mkinstalldirs /root/opt/cross /root/opt/cross
make[1]: Entering directory `/root/Desktop/src/build-gcc/i686-elf/libgcc'
make[1]: *** No rule to make target `install'.  Stop.
make[1]: Leaving directory `/root/Desktop/src/build-gcc/i686-elf/libgcc'
make: *** [install-target-libgcc] Error 2
root@slack:~/Desktop/src/build-gcc#

I'll probably have to try installing the latest Ubuntu or Gentoo and see how it goes after some tries with variations for libgcc, or just reimplement it as my own source code given that I already have the binaries, which is what probably should matter the most.

[Octocontrabass]

But there's a log for the "libgcc" subdirectory

And if you check that log, you'll notice that it has the error you saw earlier: "cannot compute suffix of object files". If you look a little higher, you can see the last command it ran before hitting that error:

Code: Select all

configure:3653: checking for suffix of object files
configure:3675:  /root/Desktop/src/build-gcc/./gcc/xgcc -B/root/Desktop/src/build-gcc/./gcc/ -B/root/opt/cross/i686-elf/bin/ -B/root/opt/cross/i686-elf/lib/ -isystem /root/opt/cross/i686-elf/include -isystem /root/opt/cross/i686-elf/sys-include    -c -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: Floating point exception

Odd errors like that indicate a broken GCC. In this case, it's probably broken because you're trying to use GCC 4.2.3 to compile GCC 6.2.0.

I'll probably have to try installing the latest Ubuntu or Gentoo and see how it goes

Those will most likely include a new enough version of GCC to successfully build a GCC 6.2.0 cross-compiler. If you still want to run under Windows for some reason, there's always MSYS2. (Note that MSYS2 doesn't include a lot of packages by default that GCC assumes are present, like tar.)

or just reimplement it as my own source code

You cannot reimplement libgcc.

[~]

It sounds and looks like an error where a program is badly or partially implemented, like when I try to implement a compiler and it's very fragile if it isn't used carefully or only with the simplest options.

In this case it's like a synonym case where a version far apart of the compiler doesn't work because there are flags that didn't exist or that were commonly disabled for some reason.

It only happened with LibGCC, not with GCC or Binutils themselves. Maybe it shows how complex, fragile and to the limits of the compiler sanity the LibGCC sources are, as well as other programs that use to fail to compile, for that matter.

I think I will try with different distros to see if it works well, and I will start with Ubuntu Desktop since it's the most common one people would have around, then I could try and see how it goes with the other distros.

[Octocontrabass]

It sounds and looks like an error where a program is badly or partially implemented, like when I try to implement a compiler and it's very fragile if it isn't used carefully or only with the simplest options. In this case it's like a synonym case where a version far apart of the compiler doesn't work because there are flags that didn't exist or that were commonly disabled for some reason.

That's not too far off from what actually happens. GCC itself is one of the best stress tests for GCC, so it tends to expose bugs and missing features in older versions. This is why you need to bootstrap GCC when there's a large version difference.

It only happened with LibGCC, not with GCC or Binutils themselves. Maybe it shows how complex, fragile and to the limits of the compiler sanity the LibGCC sources are, as well as other programs that use to fail to compile, for that matter.

The problem has nothing to do with libgcc, and everything to do with GCC 4.2.3 being unable to build a working GCC 6.2.0. If you look at the log, you can see that libgcc is the only thing being built with "/root/Desktop/src/build-gcc/./gcc/xgcc" instead of the host GCC. That xgcc is a trimmed down version of your cross-compiler. You'll probably see similar errors if you try to use the i686-elf-gcc you just built.

[~]

I made a video showing how to build the compiler under the latest Ubuntu. Version 16.04.1 contains GCC 5.4.0

It contains a description of the command lines used.
http://www.youtube.com/watch?v=nnL_Lv19hdw


The only things I wonder about is why you say that the C library cannot be reimplemented, and where is MAKE in this cross toolchain?

[Octocontrabass]

The only things I wonder about is why you say that the C library cannot be reimplemented,

I didn't say anything about the C standard library, just libgcc. You can't reimplement libgcc because it's not a standard library, it's a piece of GCC.

and where is MAKE in this cross toolchain?

Make isn't part of the toolchain.

[~]

The only things I wonder about is why you say that the C library cannot be reimplemented,

I didn't say anything about the C standard library, just libgcc. You can't reimplement libgcc because it's not a standard library, it's a piece of GCC.

and where is MAKE in this cross toolchain?

Make isn't part of the toolchain.

Is then a potential OS made solely with the programming specifications from OSDev.org wiki and forum to be compiled only with standard commands and LD scripts at most?