sparc64: bender /var/tmp/portage/sci-mathematics/pari-2.3.2/work/pari-2.3.2 # ./config/arch-osname sparcv9-linux hppa: elmer /mnt/alt/portage-tmp/portage/sci-mathematics/pari-2.3.2/work/pari-2.3.2 # ./config/arch-osname hppa-linux x86: astrid /dev/shm/portage/sci-mathematics/pari-2.3.2/work/pari-2.3.2 # ./config/arch-osname i686-linux Seems to work fine on at least these three arches, whereas the `cut' approach currently used in the ebuild breaks hppa at src_test and src_install as follows: >>> Source unpacked. >>> Compiling source in /dev/shm/portage/sci-mathematics/pari-2.3.2/work/pari-2.3.2 ... * Building for hppa2.0-linux ... >>> Source compiled. * Testing pari kernel ... Making test-kernel in Olinux-hppa Please run Configure first! make: *** [test-kernel] Error 1 [ !! ] >>> Install pari-2.3.2 into /dev/shm/portage/sci-mathematics/pari-2.3.2/image/ category sci-mathematics Making install in Olinux-hppa Please run Configure first! make: *** [install] Error 1 I suggest the ebuild is patched accordingly: $ cvs diff pari-2.3.2.ebuild Index: pari-2.3.2.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/sci-mathematics/pari/pari-2.3.2.ebuild,v retrieving revision 1.8 diff -u -B -r1.8 pari-2.3.2.ebuild --- pari-2.3.2.ebuild 1 Oct 2007 17:03:36 -0000 1.8 +++ pari-2.3.2.ebuild 1 Oct 2007 21:16:41 -0000 @@ -29,10 +30,8 @@ } src_compile() { - # Special handling for sparc local myhost - [ "${PROFILE_ARCH}" == "sparc64" ] && myhost="sparcv9-linux" \ - || myhost="$(echo ${CHOST} | cut -f "1 3" -d '-')" + myhost="$(./config/arch-osname)" einfo "Building for ${myhost}" #need to force optimization here, as it breaks without @@ -47,7 +46,7 @@ --prefix=/usr \ --datadir=/usr/share/${P} \ --libdir=/usr/$(get_libdir) \ - --mandir=/usr/share/man/man1 || die "./configure failed" + --mandir=/usr/share/man/man1 || die "./Configure failed" if use hppa then Btw, I already (revision 1.8) removed `> /dev/null' in src_test that prevented me (and, in the long run, the ebuild maintainers as well) from analysing the problem - that's worth more than a slick `ebegin; ...; eend'.
On further inspection, it appears that --host= is ignored completely by the Configure script, so I will attach an improved patch for the ebuild to this bug shortly.
(In reply to comment #1) > On further inspection, it appears that --host= is ignored completely s|completely|partly|
Created attachment 132342 [details, diff] pari-2.3.2.ebuild.patch
Created attachment 132343 [details, diff] pari-2.3.2-strip.patch
make bench fails on both hppa and sparc, by the way. test-kernel doesn't really do anything until you run it, either, except prove that you can compile something against libpari.
(In reply to comment #5) > make bench fails on both hppa and sparc, by the way. test-kernel doesn't really > do anything until you run it, either, except prove that you can compile > something against libpari. > Thank you very much for your detailed testing on hppa and sparc. Unfortunately, I don't have access to either of this arches so I can't really provide much good feedback. Much of the sparc stuff (which you propose to remove in your patch) came from the kind help of Ferris and was needed to get the src_test stuff running on sparc (see bug #141206). Hence, I am afraid that just removing it will break things again. Regarding the tests. At least on my machine "make test-kernel" does test the kernel and compare the resulting output against some reference data. Here's the relevant part from the makefile on x86 ---------------- SNIP ------------------------------------------- test-kernel:: kerntest @./kerntest > gp.out; diff -c gp.out ../src/test/32/kernel > kern.dif; if test -s kern.dif; then echo "KERNEL BUG"; else echo OK; fi ------------------------------------------------------------------- Clearly, pari has more testing capabilities (like make bench and such). But until I "understand" what is going on there and what a potential failure would mean for the functionality of pari as a whole I am hesitant to just enable it by default. Thanks, Markus
(In reply to comment #6) > Clearly, pari has more testing capabilities (like make bench and such). > But until I "understand" what is going on there and what a potential > failure would mean for the functionality of pari as a whole I am hesitant to > just enable it by default. What are you talking about? The Summary still says that it doesn't even build because of the `echo | cut` logic. Even for sparc64 that logic isn't necessary and I proposed to use pari's own arch-osname logic instead of hacking something together in the ebuild. Testing stuff is second to building it to begin with. There's a great lot with the test suite on both sparc and hppa, but this bug blocks the pari stabilisation bug because we NEED to get rid of the way $myhost is set up.
Fixed in 2.3.2-r1...
(In reply to comment #7) > What are you talking about? The Summary still says that it doesn't even build > because of the `echo | cut` logic. Even for sparc64 that logic isn't necessary > and I proposed to use pari's own arch-osname logic instead of hacking something > together in the ebuild. > This was part of my response to your comment that the current test routine does not do anything. > Testing stuff is second to building it to begin with. There's a great lot with > the test suite on both sparc and hppa, but this bug blocks the pari > stabilisation bug because we NEED to get rid of the way $myhost is set up. > I very much agree! As I said before, I have no way of testing on sparc and hppa. The part of the ebuild that seems to be the issue was provided by sparc to get the testing routines to run on their arch. If they break the actual build process on hppa then removing them is prudent. It would be nice though to resurect testing on sparc and hppa at some point. Thanks again for your help, Markus
pari-2.3.2-r1 installs fine on sparc. As to the extended tests: If I go the build directory (/var/tmp/portage/sci-mathematics/pari-2.3.2-r1/work/pari-2.3.2) and try 'make bench', it seems that the last test (nfields, run with ../src/test/dotest 32 nfields_200 from the Olinux-sparcv9 directory) never terminates. Since it does terminate on amd64, it is hard to see where the problem lies, and if this is actually an indication of problems with pari, or if it is an architectural quirk. As time permits, I'll look at it. But the nfields script is quite long, so I do not promise a resolution.
(In reply to comment #10) > pari-2.3.2-r1 installs fine on sparc. As to the extended tests: If I go the > build directory Thanks for looking into this Ferris, and this is good to know :) Please let me know if I can be of any help. cheers, Markus
(In reply to comment #10) > pari-2.3.2-r1 installs fine on sparc. As to the extended tests: If I go the > build directory > (/var/tmp/portage/sci-mathematics/pari-2.3.2-r1/work/pari-2.3.2) and try 'make > bench', it seems that the last test (nfields, run with ../src/test/dotest 32 > nfields_200 from the Olinux-sparcv9 directory) never terminates. Since it does > terminate on amd64, it is hard to see where the problem lies, and if this is > actually an indication of problems with pari, or if it is an architectural > quirk. As time permits, I'll look at it. But the nfields script is quite > long, so I do not promise a resolution. It's interesting to make test-compat too - both bench and test-compat show that either the tests are bad or that beyond x86 nothing was ever tested. There are just too many tests failing.
(In reply to comment #12) > > It's interesting to make test-compat too - both bench and test-compat show that > either the tests are bad or that beyond x86 nothing was ever tested. There are > just too many tests failing. > I'll ping upstream about this tonight; maybe they can shed some light on the status of the test routines on arches other than x86. Thanks, Markus
Go bugzilla! Thanks for re-adding my comment --- I guess your changes aren't perfect yet. For me on sparc, test-compat seems to be another test which never terminates.
(In reply to comment #13) > I'll ping upstream about this tonight; maybe they can shed some light > on the status of the test routines on arches other than x86. Please ping them as well about the --host option not working properly -- the reason this bug exists is because --host is honoured for the compile targets but not for (some of) the test and install targets. Maybe it's a good idea to open a new (Gentoo) bug -- in the long run that should help us get src_test working properly, too.
