SourceForge

Matts on 2002-06-19T12:12:17

SourceForge's compile farm is great if you don't have lots of different machines to test things on. The only problem is that their Solaris perl installation seems severely borked, in that it won't compile perl XS modules right.

Anyway, if you ever have to use cf.sourceforge.net, here's how you get XS modules to compile cleanly:

perl Makefile.PL CC=gcc LD=gcc LDDLFLAGS=-shared OPTIMIZE="-O2" CCCDLFLAGS=-fPIC

---

EBROKENPERL

rafael on 2002-06-19T12:46:35

CC=gcc ? How strange. Do you mean they have reinstalled a perl over the Solaris-provided one ? What does perl -V:cc say ?

Re:EBROKENPERL

Matts on 2002-06-19T13:19:46

I don't know *what* they've done. It's all horribly broken. I wouldn't even want to speculate. -V:cc returns "cc". But if you try and compile something with cc it breaks horribly.

Re:EBROKENPERL

davorg on 2002-06-19T15:08:38

Seen this many times on a number of different vendors' boxes. The explaination goes like this:

• Vendor pre-installs Perl on system
• Vendor also installs cut-down, non-ANSI version of cc on system
• Pre-installed version of Perl is built with vendor's much better (but not free) cc which isn't installed on system
• Sysadmin refuses to buy vendor's full version of cc and installs gcc instead
• Everything in Config.pm points to vendor's version of cc and doesn't work with gcc
• Badness ensues

Another good reason for building your own version of Perl and not relying on a pre-built version.

Re:EBROKENPERL

jdavidb on 2002-06-19T13:27:22

Last I checked, Solaris (version 7, I think, and possibly 8), needed me to do a lot of CC=gcc LD=gcc stuff to compile XS modules, but that was because I hadn't installed Sun's compiler. On some systems we made the changes directly to the Config.pm module and it worked.

However, I've left off trying to interfere with the system Perl on any machine. Even on my LFS machines there's a Perl compiled when installing the system in /usr/bin, but the Perl I use for programming and installing modules with is in /usr/local/perl561 with symlinks into /usr/local/bin, and all my programs are directly wired for #!/usr/local/bin/perl5.6.1 . I'm expecting a relatively painless transition to 5.8.

Re:EBROKENPERL

rafael on 2002-06-19T13:44:27

You remember me this (unanswered) post by Alan Burlison (Sun's Perl guy).

Re:EBROKENPERL

pudge on 2002-06-19T15:07:08

I hacked Config.pm in MacPerl to return different values based on the binary. Config.pm can have a hash called %preconfig which will allow overrides. MacPerl's looks sorta like:

{
        local $^W;
        my $inst = ($ENV{MACPERL} || "") . "site_perl:";
        my $arch = $MacPerl::Architecture || "";
        my $cc   = $MacPerl::Compiler || "";
 
        %preconfig = (
                installsitelib          => $inst,
                installsitearch         => "$inst$arch:",
                archname                => $arch,
                myarchname              => $arch,
                cc                      => $cc,
        );
}

Of course, those two $MacPerl:: vars are hardcoded into the respective binaries[*], but almost any method of dynamic discovery could be used.

* Although, MacPerl works kinda weirdly ... the last line of perlmain.c:xs_init is:

av_push(PL_preambleav, newSVpv("BEGIN { bootstrap MacPerl; bootstrap OSA; bootstrap XL;  }",0));

That's what gives us $MacPerl:: variables working automatically. The bad part here is that Config.pm when called either as -MConfig or -V will be executed *before* xs_init(), so those variables are never populated. Wheeeeee.

perl -e 'use Config "myconfig"; print myconfig'

That works, though.