OSDev.org

I suspect that on these systems libgcc is built as a shared library instead of a static one. (I haven't checked, since I haven't targeted any of those recently.)

If so, is there a straightforward way to force it to be built as a static library?

And are there any notable reasons why not to do so, and if so, how do I work around them? I can understand why those triplets would default to that, given that those target triplets are meant mainly for systems which support DLLs/shared libraries, but I would expect that there would be times when a static version would be called for even in general programming practice.

Try passing --disable-shared to configure

OK, I'll try that now. I assume that this applies only to GCC, and not to the build for binutils - though I suppose it could, for the assembler and linker.

EDIT: For the time being, I am passing it to configure in both scripts, though I don't expect it has any effect on Binutils.

There is a good chance it is building shared libraries. Windows itself does support DLLs, so libgcc ought to be build as a DLL. For freestanding environments, shared libraries won't be supported (at least at first), so we must tell configure to not use shared libs. But as Octocontrabass said, the docs are unclear as to what the defaults are.

Very well, then. I will let you know the results when the builds finish.

OK, I ran the script as it was, and got the following error:


This is the first time this error has come up so far, but it does indicate that it is at least trying to build libgcc, even if there is some problem with the C pre-processor.

I have composed a simplified version of the install script to speed up the testing, having it compile only for the single target triplet, and only for C:



Running this gives the following error message:

What I don't understand about this error is the reference to a common/ directory in the directory above the one I am invoking the script from (/home/schol-r-lea/Deployments/cross-dev-utils). I would expect that, if anything, it would use a common/ directory in /home/schol-r-lea/Deployments/cross-dev-utils/gcc, rather than going two directories up the path.

EDIT: While the /home/schol-r-lea/Deployments/common/ directory does exist, which is where all of the actual source code is kept (the directories in cross-dev-utils/ are all symbolic links to same, something I'd forgotten about) there is no libgcc/ directory there.

I know I am building from the bleeding-edge versions of the GCC source tree, but I am hesitant to assume that there is a fault in the GCC build scripts. I can only assume something is wrong with my own script, but I am unsure what it would be.

Give 10.2.0 a try perhaps? I am building it with no problems for i686-elf and x86_64-elf.

I use binutils 2.35, GCC 10.2.0 and newlib 4.0.0. Perhaps not "bleeding edge" but the latest official release.

That would make sense to at least try, OK.

EDIT: No change. Do I need to download or clone the source code for LibGCC separately from the GCC code?

I use zipped source code from here:

http://ftp.gnu.org/gnu/binutils/
http://ftp.gnu.org/gnu/gcc/gcc-10.2.0/

libgcc comes with gcc, there is no separate download.

I tried compiling the 10.2.0 release, but got the same results.

On going back to the Master build, I removed the --enable-languages option, since it seems that the default is to build all supported languages for a given target triplet, which is what I actually want.

Also, I am getting the error about the C preprocessor failing a sanity check, again. This leads me to a question: given that cpp is a separate program from the compiler, is it bundled with Binutils, or with GCC? Do they both include their own versions? Or is there a separate package for cpp which I ought to download?

Since it is apparently using the system version at lib/cpp, would the mismatch in versions (10.2.0 vs. 11.0.0) be a factor?

As a quick update, I had a brainfart last night and tried pulling the 10.2.0 tagged branch over my current local, rather than using switch, the practical upshot being that I've had to delete my local and clone it fresh. I am currently building both binutils and gcc again, and hopefully by building the releases/gcc-10 branch I'll be able to see if the discrepancy in the versions of cpp was to blame for the most recent problem.

OK, so I am still getting the failed sanity check error regarding the default version of the C preprocessor when compiling for releases/gcc-10. Something seems to be off with the Manjaro system install for CPP, or at least, the compiling scripts for libgcc seems to think there is when compiling for this given target triplet and a static version of libgcc.

Is there any way to compile CPP independently, and then force the configuration script to compile with that different version?

For now, I am going to build a separate version of GCC for the dev host target triplet (x86_64-pc-linux-gnu) and use that as a bootstrap for the successive cross compiler builds.

If I can't solve this issue, or if other issues keep arising, I may need to shift to using LLVM/Clang for this project, instead.

How come you don't just just install the mingw packages from APT? That would be a lot easier. I have had many problems with Clang, so I would stay away from it.