Working on GCC 9.4.0


I’m working on GCC 9.4.0 and I would like to share what I found during this work.

The first thing concern the use of --with-mpfr="$MPFR_path" instead of --with-mpfr=/Programs/MPFR/4.0.2 in the configure_options. RecipeLint complain about the use of /Programs/MPFR/4.0.2 with a message “ERROR: Recipe references /Programs tree explicitly. Use $target and $_path.”

So, I followed the recommendation by using “$MPFR_path” but that create an issue as you can see below. ( I have truncated the output ).

With "$MPFR_path"

./build-x86_64-pc-linux-gnu/libiberty/config.log:Configured with: --with-mpfr=/Programs/MPFR/4.0.2

./build-x86_64-pc-linux-gnu/libiberty/config.status:ac_cs_config=" '--with-mpfr=' "

With /Programs/MPFR/4.0.2

./build-x86_64-pc-linux-gnu/libiberty/config.log:Configured with: --with-mpfr=/Programs/MPFR/4.0.2

./build-x86_64-pc-linux-gnu/libiberty/config.status:ac_cs_config=" '--with-mpfr=/Programs/MPFR/4.0.2' "

The second thing I have notice is the ldd output on some built librairies.

ldd /Programs/GCC/9.4.0/lib/ (0x00007ffdd1684000) => /usr/lib/../lib/ (0x00007fa5c76b9000) => /usr/lib/../lib/ (0x00007fa5c76b0000) => /usr/lib/../lib/ (0x00007fa5c768f000) => /usr/lib/../lib/ (0x00007fa5c749d000) => /usr/lib/../lib/ (0x00007fa5c7359000) => /usr/lib/../lib/ (0x00007fa5c7191000) => /usr/lib/../lib/ (0x00007fa5c7176000)

        ldd /Programs/GCC/9.4.0/lib/ (0x00007ffd26e5b000) => /usr/lib/../lib/ (0x00007f80f07e1000) => /usr/lib/../lib/ (0x00007f80f069d000) => /usr/lib/../lib/ (0x00007f80f0684000) => /usr/lib/../lib/ (0x00007f80f04bc000)
        /lib64/ (0x00007f80f0ac0000)

        ldd /Programs/GCC/9.4.0/lib/ (0x00007ffc5e1bd000) => /usr/lib/../lib/ (0x00007f504aeb3000) => /usr/lib/../lib/ (0x00007f504aeaa000) => /usr/lib/../lib/ (0x00007f504ae89000) => /usr/lib/../lib/ (0x00007f504ac97000) => /usr/lib/../lib/ (0x00007f504ab53000) => /usr/lib/../lib/ (0x00007f504a98b000)
        /lib64/ (0x00007f504b7a7000) => /usr/lib/../lib/ (0x00007f504a970000)
        ldd /Programs/GCC/9.4.0/lib/ (0x00007ffe379ba000) => /usr/lib/../lib/ (0x00007fb2cbdf1000) => /usr/lib/../lib/ (0x00007fb2cbde8000) => /usr/lib/../lib/ (0x00007fb2cbdc7000) => /usr/lib/../lib/ (0x00007fb2cbbd5000) => /usr/lib/../lib/ (0x00007fb2cba91000) => /usr/lib/../lib/ (0x00007fb2cb8c9000) => /usr/lib/../lib/ (0x00007fb2cb8ae000)
        /lib64/ (0x00007fb2cc915000)
        ldd /Programs/GCC/9.4.0/lib/ (0x00007ffe3c5f2000) => /usr/lib/../lib/ (0x00007f1d71891000) => /usr/lib/../lib/ (0x00007f1d71888000) => /usr/lib/../lib/ (0x00007f1d71867000) => /usr/lib/../lib/ (0x00007f1d71675000) => /usr/lib/../lib/ (0x00007f1d71531000) => /usr/lib/../lib/ (0x00007f1d71369000) => /usr/lib/../lib/ (0x00007f1d7134e000)
        /lib64/ (0x00007f1d721ff000)

but I don’t know how to fix this.

And to terminate, GCC doesn’t care about LIBTOOL variable, I tried to export LIBTOOL=${goboExecutables}/libtool in the Recipe, using Environment file, I even tried to copy Gobo libtool to the root of the GCC source, not working.

A copy of Gobo libtool during the compilation as shown below fix the installation issue

cp /usr/bin/libtool gcc-9.4.0/_build/x86_64-pc-linux-gnu/libbacktrace
cp /usr/bin/libtool gcc-9.4.0/_build/x86_64-pc-linux-gnu/libsanitizer 
cp /usr/bin/libtool gcc-9.4.0/_build/x86_64-pc-linux-gnu/libgfortran

For now, in more elegant way patching is a solution and it’s working.

-           func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir"
+           func_echo "GoboLinux: installing '$file' to $destdir"
1 Like

$MPFR_path will expand to /Programs/MPFR/<version> – but it requires that you provide an entry for MPFR in the recipe’s Dependencies file. If for some reason MPFR is not listed there anymore, or if it requests a version that’s not available, then you may get issues on the expansion of that variable. My suggestion for you is to double check if you have a valid Dependencies file first.

I’m not sure I understand what’s wrong with the output of ldd. Are you annoyed by /usr/lib/../lib/?

Yeah, I had to resort to a similar approach with the version of libtool shipped with Gobo. Please take a look at the two patches in the URL below. One of the patches, for instance, is likely to fix the /lib/../lib construction that you’ve spotted before.


Thank you for taking the time to respond.

This is exactly the process that I followed and that’s exactly what i thought to do. So with the help of your patches and some times past in the source files, I made patches for GCC 9.4.0 and I watched the result. The same thing happen when I run ldd on the librairies.

What I have noticed and maybe it’s the reason that doesn’t change anything on the librairies listed is that compiler_lib_search_path= , compiler_lib_search_dirs= , predep_objects= , postdep_objects=
are non-existent in libtool file.

Not annoyed at all but if it can be fixed to be more elegant :heart_eyes: why not do it.

It could be that they’re just named differently on the version of the script you have at hand. I’ve seen that before and simply adjusted the patch.