SOLVED! (was: Re: Should I turn MATH_EMULATE back on?)
Guess what? After some serious debugging, I found the cause. Test 19, of Hires, which gets the system time, failed because of a Vmware GSX 2.5.1 Server bug: vmx| MStat: Creating Stat vm.uptime vmx| GetSystemTimeAdjustment returned unknown clockInterval 100144 I had some other oddities with it as well. I went back to Vmware Workstation 4 for (simply remounted everything), and everything compiled ok again. Thanks for your time anyway. - Mark - Original Message - From: "Matthew Seaman" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, March 07, 2004 9:03 PM Subject: Re: Should I turn MATH_EMULATE back on? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Should I turn MATH_EMULATE back on?
- Original Message - From: "Matthew Seaman" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, March 07, 2004 9:03 PM Subject: Re: Should I turn MATH_EMULATE back on? > On Sun, Mar 07, 2004 at 07:07:54PM +, Mark wrote: > > > This is weird. I installed Perl 5.8.2_5 on a clean FreeBSD 4.9R-p3 box, > > and got an error on Time::Hires. > However, I'm running a non-threaded perl: I suspect that may be the > root cause of your problem. Just a few wild guesses here: did you > recently reinstall perl changing from non-threaded to threaded? No. This is a completely new, and clean installation of FreeBSD 4.9R-p3. Yesterday I downloaded 4.9R too, and upgraded to STABLE. When I installed Perl 5.8.2_5 then, everything went fine. Today, I changed my mind about STABLE, and decided I feel safer running a RELEASE version; so I scrubbed the disk again, installed a new 4.9R, and CVSup-ed to 4.9R-p3. Then I tried to install Perl 5.8.2_5 again; but, this time, it failed. There are only two things different since yesterday; 1): I commented out MATH_EMULATE; that potential reason you just eliminated. 2): I no longer run STABLE, but 4.9R-p3. > Do > you have perl modules still around which were compiled under the > non-threaded perl? Or perhaps you've compiled perl using higher than > normal optimization settings, or gcc33 instead of the default > compiler: No. I am not enough of a C wizard to mess with such settings. :) I just ran: make PREFIX=/usr/local/perl-threaded WITH_THREADS >From the ports. And I downloaded the very latest ports.tar.gz for that. > % perl -V:cc > % perl -V:gccversion > % perl -V:optimize Here is the result: asarian-host# /usr/local/perl-threaded/bin/perl -V:cc cc='cc'; asarian-host# /usr/local/perl-threaded/bin/perl -V:gccversion gccversion='2.95.4 20020320 [FreeBSD]'; asarian-host# /usr/local/perl-threaded/bin/perl -V:optimize optimize='-O -pipe '; asarian-host# Thanks, - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Should I turn MATH_EMULATE back on?
On Sun, Mar 07, 2004 at 07:07:54PM +, Mark wrote: > This is weird. I installed Perl 5.8.2_5 on a clean FreeBSD 4.9R-p3 box, and > got an error on Time::Hires. > Does Hires use a math co-processor? The only difference with the kernel I > ran yesterday, is that I commented out this: > > # optionsMATH_EMULATE > > On an AMD XP-2200; as I take it it has the co-processor. Still, could that > be what is causing Hires to fail? More importantly, should I turn > MATH_EMULATE back on for the AMD? Well, I have MATH_EMULATE commented out in my kernel config, and Time::Hires works perfectly well for me. This is with: % pkg_info -I perl-\* perl-5.8.2_5Practical Extraction and Report Language MATH_EMULATE applies to very early models in the x86 series where the FPU wasn't always built into the chip. I think the last models where that was true were some of the 486 chips. Certainly pentium class or better x86 chips (ie. anything introduced in the last ten years or so) have all had built in FPUs. That includes everything built by AMD as well. However, I'm running a non-threaded perl: I suspect that may be the root cause of your problem. Just a few wild guesses here: did you recently reinstall perl changing from non-threaded to threaded? Do you have perl modules still around which were compiled under the non-threaded perl? Or perhaps you've compiled perl using higher than normal optimization settings, or gcc33 instead of the default compiler: % perl -V:cc % perl -V:gccversion % perl -V:optimize will show you what was used. As with the kernel, turning on the higher levels of optimization does not necessarily make things run faster, and may well stop things running correctly at all. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
