Hello list,
Long time lurker, first time poster.
Welcome :)
I'm trying (and I think I've succeeded) to build mod_perl 1.3.29 64-bit with apache 1.3.31 on Solaris 8. Perl 5.8.4 compiled 64-bit successfully. The problem I'm having is that modperl's Makefile.PL mutilates the CFLAGS that perl built with. Specifically, it replaces commas with spaces, as seen here (line 537):
if($PERL_EXTRA_CFLAGS) {
$PERL_EXTRA_CFLAGS = join(" ", split(",", $PERL_EXTRA_CFLAGS));
$PERL_EXTRA_CFLAGS =~ s/\s+/ /g;
}
Googling turned up: http://mathforum.org/epigone/modperl/yandqueube
Does it really need to do this? No offense, but it appears to be a rather inelegant way to replace commas, so it screams "last-minute hack fix" that has lived on a for a year and half.
The problem is that there is specific flag we built perl with, "-Wa,xarch=v9", which gets turned into "-Wa xarch=v9", which makes gcc rather unhappy:
======== Error Output for sanity check ========
cd ..; gcc -DSOLARIS2=280 -DNO_DBM_REWRITEMAP -DMOD_PERL
-DUSE_PERL_SSI -mcpu=v9 -m64 -mcpu=v9 -m64 -Wa,-xarch=v9 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DNO_DL_NEEDED -mcpu=v9
-m64 -mcpu=v9 -m64 -Wa -xarch=v9 -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 `./apaci` -I.
-I/usr/local/perl-5.8.4-64_bit/lib/5.8.4/sun4-solaris-64/CORE -m64
-o helpers/dummy helpers/dummy.c -lsocket -lnsl -lpthread -L/usr/local/lib -m64 /usr/local/perl-5.8.4-64_bit/lib/5.8.4/sun4-solaris-64/auto/DynaLoader/DynaLoader.a
-L/usr/local/perl-5.8.4-64_bit/lib/5.8.4/sun4-solaris-64/CORE -lperl
-lsocket -lnsl -ldl -lm -lc
gcc: language arch=v9 not recognized
gcc: language arch=v9 not recognized
ld: fatal: file helpers/dummy.c: unknown file type
ld: fatal: File processing errors. No output written to helpers/dummy
collect2: ld returned 1 exit status
make: *** [dummy] Error 1
============= End of Error Report =============
I commented out those 4 lines in Makefile.PL, rather than try to figure out what it was trying to do, built it, and all tests passed.
That's the unfortunate result of not leaving comments when coding :( If you have time please browse http://cvs.apache.org/viewcvs.cgi/modperl/Makefile.PL and try to figure out when this change was done and hopefully there will be a reason logged in the commit message. This certainly needs to be fixed, but we need to know first why that s/// was added there in first place. Otherwise by fixing your problem we will break someone's else code.
It should be possible to automate this search by getting cvs version bumped up incrementally and grepping for that split line, untill the change is found. It'd be a nice addition to our toolset. May be someone has writen such already, shouldn't take more than a few lines of perl or sh code.
That said, the reason we're building it 64-bit is because we need MySQL 64-bit (because of some insanely large self-joins and other madness), and DBD::mysql won't build with 64-bit mysql libraries with a 32-bit perl. So maybe the real solution is a 32-bit DBD::mysql but a 64-bit mysqld -- we'll try that next, but I figured I'd ask if there's a reason for this mod_perl craziness in case we're stuck with 64-bit everything.
You mean, you need -Wa,xarch=v9 to build 64b?
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
