perl "remembers" spack's compiler, which does the wrong thing

[hartzell]

Additional Perl packages (e.g. from CPAN) should (need to) be built with the same compiler that built perl itself.

Perl handles this detail by remembering the compiler with which it was built. It "remembers" it by stashing a copy of it in the Config hash defined in Config.pm:

tie %Config, 'Config', {
    archlibexp => '/home/hartzelg/tmp/spack-perl-cc/opt/spack/linux-centos7-x86_64/gcc-4.8.5/perl-5.24.1-35ejv4426dmzreum4ekdibu3ddmhquvi/lib/5.24.1/x86_64-linux',
    archname => 'x86_64-linux',
    cc => 'cc',
    # [...]

On my system this drags /usr/bin/cc into the fray, resulting in sadness.

As an example, using the cpanm that Spack built

cpanm -l /path/to/library/dir XML::Simple

will eventually fail while trying to build Net::HTTP because it tries to use cc as its compiler.

As a quick hack/test, telling configure to use gcc as the C compiler results $Config{cc} containing gcc and happily the first gcc on my path is the one I used to build Perl.

diff --git a/var/spack/repos/builtin/packages/perl/package.py b/var/spack/repos/builtin/packages/perl/package.py
index 10895f60..ed30bac5 100644
--- a/var/spack/repos/builtin/packages/perl/package.py
+++ b/var/spack/repos/builtin/packages/perl/package.py
@@ -86,7 +86,8 @@ class Perl(Package):  # Perl doesn't use Autotools, it should subclass Package
             '-des',
             '-Dprefix={0}'.format(prefix),
             '-Dlocincpth=' + self.spec['gdbm'].prefix.include,
-            '-Dloclibpth=' + self.spec['gdbm'].prefix.lib
+            '-Dloclibpth=' + self.spec['gdbm'].prefix.lib,
+            '-Dcc=gcc'
         ]

         # Discussion of -fPIC for Intel at:

This changes lets Net::HTTP build and install.

Spack's compiler wrappers and etc seem magical to me. What's a good way to fix this?

[adamjstewart]

This snippet:

tie %Config, 'Config', {
    archlibexp => '/home/hartzelg/tmp/spack-perl-cc/opt/spack/linux-centos7-x86_64/gcc-4.8.5/perl-5.24.1-35ejv4426dmzreum4ekdibu3ddmhquvi/lib/5.24.1/x86_64-linux',
    archname => 'x86_64-linux',
    cc => 'cc',
    # [...]

Is this a text file somewhere in the installation? Can we filter it post-install like we do for the MPI wrappers?

[tgamblin]

Look at the mpich or openmpi packages to see what needs to happen here.

[hartzell]

@adamjstewart -- yes, here .../opt/spack/linux-centos7-x86_64/gcc-4.8.5/perl-5.24.1-35ejv4426dmzreum4ekdibu3ddmhquvi/lib/5.24.1/x86_64-linux/Config.pm in this perl (YYMV).

@tgamblin -- will do.

[steffen-AEI]

For whichever reason, I stumbled over this misbehaviour only this week, after a fresh checkout.

My system has gcc 4.8.5 installed, and usually I build the latest gcc version in two stages, using (1) 4.8.5 to build 9.2.0, then (2) using that to build 9.2.0 again. As a result, I would get rid of everything built with 4.8.5 (and indeed, a "spack uninstall %gcc@4.8.5" didn't report any conflicts), living on with a gcc-9.2.0 tree only.

perl, and libtool FWIW, still kept a memory of the old bootstrapping gcc (perl in Config.pm and Config_heavy.pl in lib/5.30.0/*multi/; libtool in ... yes, bin/libtool). Fortunately, those are text files easily tweaked with "sed". Afterwards, "perl-html-parser" built fine.

How come this issue could resurface at all?