An update on the previous version.
The produced gcc compiler builds static executables and no dynamically linked executables.
The compiler produced with the previous releases worked with several distributions but mysteriously failed for some. It seemed that the directory /usr/include/x86_64-linux-gnu was added by some developer to the include path on systems that support this directory. The files under that directory are specific for the GNU C Library and fail when included in MUSL C based builds. Of course, you wonder why this directory is always included and it turns out this is part of the default specfile for gcc1.
Before removing the line from the configuration, I wanted to know the history and possible usefulness of this item. The line can be found in the gcc/config/i386/gnu-user64.h file. My first step was the gcc git repository, this configuration item was not in the current source or in any previous version of gcc. Next up was the AdaCore release and it did include the item. Could it be that this was copied from any distribution? debian, gentoo and redhat all do not include a patch for gcc with this item. In short it's a specific line added by a developer at or for AdaCore. If I would take a guess at the usefulness of this item, I would propose this scheme; The AdaCore compilers can live in any directory and may be used to build code that contains system specific files, the compiler has tricks to find these files but always in relation to the path of the compiler. The binary compiler package does not include those files (and as these have a very close relation to the version of the GNU C library on the system, cannot contain those files and always work). To make gcc find the right path by default, this solution was found and implemented. This guess plus the problem that a MUSL C based gcc compiler cannot use the files in gcc/config/i386/gnu-user64.h plus the observation that the default gcc source-code does not include the line warrants removal of the line2.
Still undetermined, why does compilation sometimes work with the previous version of the code? Some systems do not include a /usr/include/x86_64-linux-gnu directory, but others do and still the compilation does not fail. I'll have to install more distributions to figure this one out, or if you have such a system, could you compile something with: gcc -v -Wmissing-include-dirs and report on the output?
For detailed instructions in how to run the script see the readme-2018-09-24.txt.
- The scripts: ada-musl-cross-2018-09-24.tgz.
- A description with my signature: ada-musl-cross-2018-09-24.txt.
- In the past year, I've bumped against this specific configuration item before and I even changed the path for an AdaCore gcc installation. I was lazy and stupid and did not look into it any further. [↩]
- To see the result of the algorithm that gcc uses for the compile path do: gcc -v -Wmissing-include-dirs [↩]
[...] and other platforms that tracks newer gcc versions. This suggests it could be forked and built on a Republican toolchain without too much fussing. If I have a free hand in 5-10 years I might try [...]
[...] ave1's gnat is the current cannonical version, I decided to try diana_coman's adacore gnat alone to see if it'd [...]
[...] The S.MG Test server runs 3 different incarnations of Ave1's GNAT: the ZCX variant which is obtained as a straight compilation using Ave1's scripts from the 15th of July 2018; the SJLJ-compilation of the same (i.e. supporting both dynamic and static linking); the SJLJ compilation of the latest, static-only version from September 2018 . [...]
[...] Ave1's GNAT version 2018-09-24 fixing an issue with a hard-coded path. [...]
[...] a musltronic GNAT for Cuntoo. Today, I wanted to write about my success with building ave1's latest version 2018-09-24, as I said I would in the previous [...]
[...] to http://ave1.org/2018/building-gnat-on-musl-no-more-usrincludex86_64-linux-gnu/ and follow the excellent [...]
[...] looking into the publications of the now disbanded Republic and asking around, I found a series of recipes, notes, more notes, and a partial collection of dependencies, but little assurance that I'd [...]