ghc-6.10.3_6 configure fails due to perl version

[league@…]

Although the portfile asks specifically for perl5.8, the configure now dies with the message "your version of perl probably won't work". Transcript attached. Revision 1 built fine on this system.

[gwright@…]

My build runs fine (10.5.7/intel). From the log, it appears as if your perl is failing a configuration test (executing a minimal script). Is your perl5.8 broken? From the available evidence, this is not a ghc problem.

[league@…]

My Perl seems to be okay. The failure just comes from the version test:

   $PerlCmd -v >conftest.out 2>&1
   if grep "v5" conftest.out >/dev/null 2>&1; then

but /opt/local/bin/perl5.8 clearly should pass

# /opt/local/bin/perl5.8 -v

This is perl, v5.8.9 built for darwin-2level
[...]

Here is a strange addendum: if I go to the work/ghc-6.10.3 directory and manually run ./configure, it finishes just fine. Even if I put all the same parameters. But it consistently fails when I try to configure using `port'.

[league@…]

Indeed my perl was broken. otool revealed that it was linked with /usr/local/lib/libgcc_s, which had since disappeared. Still mystified why this didn't cause any problems when running configure manually. But rebuilding perl seems to have done the trick. Thanks!

[gwright@…]

No mystery: when you build with 'port' the Portfile forces the use of MacPorts perl5.8. This was broken in your setup. When you run 'configure' manually, you get the first perl on your PATH, probably the system perl, /usr/bin/perl.

At the moment on 10.5.7, /usr/bin/perl is version 5.8.8, which is probably OK for building ghc. But the configuration checks are not sufficient to tell if the detected version is up to snuff, so the Portfile forces a version known to work on all platforms.

Yes, it's ugly for ghc to depend on perl at all. For the last three years it has been slated for removal Real Soon Now.

[league@…]

Except that the first perl on my path was the (broken) MacPorts perl5.8, and I even tried to simulate what port was doing by forcing export PerlCmd=/opt/local/bin/perl5.8 and configure claimed it was using that one... still it worked by hand but not through port. So I'm still mystified. :)

But this doesn't matter: ghc works, and I can't experiment with the broken perl anymore unless I restore it from backup... not worth it! Thanks again.

[gwright@…]

If that's true, I'm mystified too. A full build log shows that ghc does respect the PerlCmd environment variable.

I'll leave this closed; if there is more than a broken perl causing this bug someone can reopen it.