#9053: BUG gmp: crash in config.guess due to mfpvr instruction ----------------------------------------+----------------------------------- Reporter: vincent-opdarw@… | Owner: gwright@… Type: defect | Status: reopened Priority: Low | Milestone: Port Bugs Component: ports | Version: 1.0 Resolution: | Keywords: Port: gmp | ----------------------------------------+----------------------------------- Comment(by vinc17@…): Replying to [comment:26 mcalhoun@…]:
The test suite passed in 32 bit mode.[[BR]] The test suite passed in 64 bit mode.[[BR]] Since I only have access to the one G5 machine, such testing will have to suffice even if it does not qualify as having "tried hard."[[BR]] Is there any reason to believe this is not correct?
The correctness of arch-related options only matters if you try the binary on a different machine. So, if you test the library only on your machine, you're not doing any real test concerning these options.
I would respectfully suggest that unless the patch is quite small, there is no reason for it.[[BR]]
The patch is small (I could make it even smaller by changing only one line, e.g. with a reinplace in the Portfile, but I think that the way it is is cleaner and 5 KB is not too much).
Correct me if I am wrong, but the crash is part of a normal test process.[[BR]]
No, this is not normal. The test in question (where the crash occurs) is designed for Linux. I wonder why it isn't disabled on other systems (at least on those where this particular test is known to fail, as documented).
Code is run, it fails, and so the configure script knows not to run that code.[[BR]]
No. The configure script runs config.guess, but only uses its output. But removing the mfpvr test doesn't change the config.guess output since this test fails to give any information on the processor. Under Mac OS X, the information on the processor is given by the test designed for Mac OS X (or more generally Mach-O). Note: it is theoretically possible to make the AIX test "work" and return an incorrect result (thus making the GMP build fail) by adding a sys/systemcfg.h header to the system (I don't think there's anything wrong with that, because sys/systemcfg.h isn't standard under Mac OS X thus well-written software shouldn't use it), even though this is quite unlikely in practice (but remember that there was a real problem with malloc.h, and this was quite similar). However since there's a patch, it was the occasion to remove the second buggy test. -- Ticket URL: <http://trac.macports.org/ticket/9053#comment:27> MacPorts <http://www.macports.org/> Ports system for Mac OS