Summary: | Please keyword sys-cluster/openmpi-1.2.6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Justin Bronder (RETIRED) <jsbronder> |
Component: | New packages | Assignee: | Gentoo Cluster Team <cluster> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | fmccor |
Priority: | High | Keywords: | KEYWORDREQ |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 225045 | ||
Attachments: | gentoo-x86/sys-cluster/openmpi/files/openmpi-1.2.6-hppa.patch |
Description
Justin Bronder (RETIRED)
2008-04-04 00:39:45 UTC
added ~ppc64 Keyworded on alpha. Adding sparc, see #217854. Then why not add all relevant arches? I know of one... (In reply to comment #4) > Then why not add all relevant arches? I know of one... Glad you caught that as mpich was stabled for hppa after I filed this bug and I hadn't been monitoring that ebuild. ;) Added ~sparc. ompi_info works as it should. I have used this product on sparc and know that it should work well, but I have no extensive tests close at hand. That said, this package comes with an extensive test suite. However, for some reason 'FEATURES=test emerge -v openmpi' does not run it. So, I ran it by hand. All tests pass. Thanks, Justin, for bringing this to our attention. Hmm, sadly openmpi has not been ported to PARISC Linux... Debian doesn't have a port either. All in all it wouldn't make sense to port a high performance app to a dying architecture, so any porting patch may not even be accepted upstream now. ppc arch team: I have access to a ppc machine (dual G4) and have upload the results of compiling and testing to my devspace. I don't know if it matters or what your policy on keywording is, but maybe this could help move things along? http://dev.gentoo.org/~jsbronder/ppc-openmpi-1.2.5-logs.tar.bz2 (In reply to comment #6) > That said, this package comes with an extensive test suite. However, for some > reason 'FEATURES=test emerge -v openmpi' does not run it. So, I ran it by > hand. All tests pass. Sorry about that. Luckily 1.2.6 is out, so I'll be sure to check this functionality before commiting. (In reply to comment #8) > ppc arch team: I have access to a ppc machine (dual G4) and have upload the > results of compiling and testing to my devspace. I don't know if it matters or > what your policy on keywording is, but maybe this could help move things along? > http://dev.gentoo.org/~jsbronder/ppc-openmpi-1.2.5-logs.tar.bz2 Feel free to keyword it. In general if you can test it on ppc hardware, you can add ~ppc keywords. When in doubt, just poke on of us. And thanks for testing :-) added ~ppc. I think we're done unless you want to keep this open for hppa Jeroen? Er, well I stated there are issues, but I am not Gentoo's contact to $UPSTREAM so suppose if they have a lingering patch that could provide hppa support, then I am not the one to go find out. :) Closing as I have no access to hppa stuff ;) Also, I just put 1.2.6 in the tree which fixes the missing src_test() stuff. dev-libs/boost-1.35.0-r1 now depends on some mpi. mpich is too old, mpich2 depends on Java, which hppa doesn't currently do, which leaves openmpi. Created attachment 157045 [details, diff]
gentoo-x86/sys-cluster/openmpi/files/openmpi-1.2.6-hppa.patch
Something like this ought to work. It passes the point where it failed before:
checking for asssembly architecture... HPPA
checking for perl... perl
checking for pre-built assembly file... no (not in asm-data)
checking whether possible to generate assembly file... failed
configure: WARNING: Could not build atomic operations assembly file.
configure: WARNING: There will be no atomic operations for this build.
checking for atomic assembly filename... none
*** Fortran 77 compiler
[...]
But then it fails further on in econf:
*** Libtool configuration
checking for a sed that does not truncate output... /bin/sed
checking for ld used by hppa2.0-unknown-linux-gnu-gcc... /usr/hppa2.0-unknown-linux-gnu/bin/ld
checking if the linker (/usr/hppa2.0-unknown-linux-gnu/bin/ld) is GNU ld... yes
checking for /usr/hppa2.0-unknown-linux-gnu/bin/ld option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for dlfcn.h... (cached) yes
checking how to run the C++ preprocessor... hppa2.0-unknown-linux-gnu-g++ -E
checking the maximum length of command line arguments... 98304
checking command to parse /usr/bin/nm -B output from hppa2.0-unknown-linux-gnu-gcc object... ok
checking for objdir... .libs
checking for hppa2.0-unknown-linux-gnu-ar... hppa2.0-unknown-linux-gnu-ar
checking for hppa2.0-unknown-linux-gnu-ranlib... hppa2.0-unknown-linux-gnu-ranlib
checking for hppa2.0-unknown-linux-gnu-strip... hppa2.0-unknown-linux-gnu-strip
checking for correct ltmain.sh version... no
configure: error:
*** [Gentoo] sanity check failed! ***
*** libtool.m4 and ltmain.sh have a version mismatch! ***
*** (libtool.m4 = 1.5.26, ltmain.sh = 2.1a) ***
Please run:
libtoolize --copy --force
if appropriate, please contact the maintainer of this
package (or your distribution) for help.
make: *** [config.status] Error 1
(In reply to comment #13) > dev-libs/boost-1.35.0-r1 now depends on some mpi. mpich is too old, mpich2 > depends on Java, which hppa doesn't currently do, which leaves openmpi. > mpich2 no longer relies on java and openmpi has come a long way since 1.2.6. See also #324417 for more reasoning to look into one of these two packages. 1.4.3 has the same problem. Declining in favour of mpich2, bug #324417. Closing. |