Realized it just after I hit "send". Mail is moving rather quickly today...
> -----Original Message----- > From: Stas Bekman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 28, 2004 4:48 PM > To: Barksdale, Ray > Subject: Re: compile problems > > Ray, please followup to the list as a reply to that thread, > so others will > be able to learn from your mistakes. And we will take it from > there. Thanks. > > Barksdale, Ray wrote: > >>-----Original Message----- > >>From: Stas Bekman [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, December 22, 2004 6:02 PM > >>To: Barksdale, Ray > >>Cc: modperl@perl.apache.org > >>Subject: Re: compile problems > >> > >> > >>OK, so it has something to do with 64-bit-ness. But I didn't > >>understand. > >>Was this problem seen on a 64-bit CPU or on a 32-bit CPU, but > >>then code > >>was compiled for 64-bit? > > > > > > The problem (more of an observation at this point) was the apparent > > excessive memory usage of Apache2/mod_perl2 (64-bit build) on top > > of 64-bit Linux (RedHat Fedora Core 2 - AMD64 distribution). > > > > We built perl/Apache/mod_perl/libapreq/etc/etc.... in the > same fashion > > as we had for our 32-bit environment (again RedHat Fedora > Core 2 - x86). > > The memory load was normal. > > We were not doing any crosscompiles of 64 to 32 or viceversa. > > > > I had a brain fart. We (read "me") got crossed up on what > -m64 caused > > gcc to do. I read the docs and understood this to cause gcc > to force > > the usage of the additional registers on the opteron. This is the > > default behavior when building (note to self...) in the > 64-bit environment. > > Also found that there is a -march=k8 option (again a > default in 64-bit > > land). > > > > As far as the memory usage problem I thought I was on to > the source when > > I stripped my httpd binary and went from: > > > > VIRT RES SHR > > 76232 3856 73m > > to > > 17524 2064 15m > > > > (both without mod_perl) but this resulted in a minimal gain once > > mod_perl was loaded. > > > > I'll keep digging arround though. > > > > > > > >>>On the bright side everything runs perfectly (in a bloated > >> > >>sort of way ;) > >> > >>>Thanx a load. > >> > >>I didn't do anything :) > > > > > > Well, for all my rootin' (as they say in Arkansas) I didn't > either :{ > > > > > > > >> > >>-- > >>__________________________________________________________________ > >>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 > >> > > > > > > > > *****CONFIDENTIALITY NOTICE***** > > This e-mail and any files or attachments may contain > confidential and > > privileged information. If you have received this message > in error, please > > notify the sender at the above e-mail address and delete it > and all copies > > from your system. > > > > > -- > __________________________________________________________________ > 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 > *****CONFIDENTIALITY NOTICE***** This e-mail and any files or attachments may contain confidential and privileged information. If you have received this message in error, please notify the sender at the above e-mail address and delete it and all copies from your system. -- 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
