Repository: spack/spack

Issue:
gcc: build issue on aarch64
Spack is failing to build gcc on ARM systems using our side-installed gcc compilers:

[lee218@ulna2:spack-gcc-arm]$ ./bin/spack install --keep-stage gcc@9.2.0%gcc@7.3 

...

  >> 10226    /tmp/lee218/spack-stage/spack-stage-gcc-9.2.0-fm7js2yexc7zo54qv54
              jjanbxft5jorq/spack-src/spack-build/./gcc/cc1: error while loadin
              g shared libraries: libisl.so.19: cannot open shared object file:
               No such file or directory

On our ARM systems, the side-installed gcc compiler (i.e., /opt/rh/devtoolset-7/root/bin/gcc ) hardcodes LD as /opt/rh/devtoolset-7/root/usr/libexec/gcc/aarch64-redhat-linux/7/ld. This is found by configure when running gcc -print-prog-name=ld:
 
[lee218@ulna2:spack-src]$ /opt/rh/devtoolset-7/root/bin/gcc -print-prog-name=ld
/opt/rh/devtoolset-7/root/usr/libexec/gcc/aarch64-redhat-linux/7/ld
 
Effectively, this finds anything in the in th/opt/rh/devtoolset-7/root/usr/libexec/gcc/aarch64-redhat-linux/7 directory and will print the full path, otherwise, it will just echo the “-print-prog-name” value:
 
[lee218@ulna2:spack-src]$ /opt/rh/devtoolset-7/root/bin/gcc -print-prog-name=blahblahblah
blahblahblah
 
With most of our other gcc builds (on x86 systems, /usr/bin/gcc on x86 and arm, spack-built gcc, etc.), the search directory does not contain ld and thus the command just prints “ld” and effectively uses Spack’s wrapper and gets the necessary rpaths for libisl.so.

This method of finding ld is in gcc's configure script, so one solution may be to add a patch that modifies the configure script to avoid using the full-path ld and just use ld instead. I'm not sure if there are any unintended consequences. It's also not clear to me at this point whether other configure scripts do similar things and thus merits a more general solution.



Discussion:
Moving this to 0.14 and assigning to @becker33.  We need to fix this but it won't be in for 0.13.2.
Do we think this will still make it in for 0.14?

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/gcc/package.py b/var/spack/repos/builtin/packages/gcc/package.py
--- a/var/spack/repos/builtin/packages/gcc/package.py
+++ b/var/spack/repos/builtin/packages/gcc/package.py
@@ -335,15 +335,9 @@ def configure_args(self):
 
         # Binutils
         if spec.satisfies('+binutils'):
-            stage1_ldflags = str(self.rpath_args)
-            boot_ldflags = stage1_ldflags + ' -static-libstdc++ -static-libgcc'
-            if '%gcc' in spec:
-                stage1_ldflags = boot_ldflags
             binutils = spec['binutils'].prefix.bin
             options.extend([
                 '--with-sysroot=/',
-                '--with-stage1-ldflags=' + stage1_ldflags,
-                '--with-boot-ldflags=' + boot_ldflags,
                 '--with-gnu-ld',
                 '--with-ld=' + binutils.ld,
                 '--with-gnu-as',
@@ -376,6 +370,14 @@ def configure_args(self):
                 '--with-libiconv-prefix={0}'.format(spec['iconv'].prefix)
             ])
 
+        # enable appropriate bootstrapping flags
+        stage1_ldflags = str(self.rpath_args)
+        boot_ldflags = stage1_ldflags + ' -static-libstdc++ -static-libgcc'
+        if '%gcc' in spec:
+            stage1_ldflags = boot_ldflags
+        options.append('--with-stage1-ldflags=' + stage1_ldflags)
+        options.append('--with-boot-ldflags=' + boot_ldflags)
+
         return options
 
     # run configure/make/make(install) for the nvptx-none target


Test patch: