The URL points to the openmpi in the gentoo-science overlay. Note that it's structured to accommodate slotting of the mpi ebuilds (this is becoming a requirement). The eclass (not written as of yet) has to be user callable. One approach I see of doing this eclass for the moment would be to show the available implementations and, once one is selected, display the lines to add to their .bashrc (or equivalent). I don't think we can "play" with a user's shell config file as it would be rather dangerous and non-deterministic ;).
OpenMPI won't build with Torque installed (on amd64 only, PIC issue): x86_64-pc-linux-gnu-gcc -shared .libs/pls_tm_component.o .libs/pls_tm_module.o -Wl,--rpath -Wl,/var/tmp/portage/openmpi-1.0.1/work/openmpi-1.0.1/orte/.libs -Wl,--rpath -Wl,/var/tmp/portage/openmpi-1.0.1/work/openmpi-1.0.1/opal/.libs -Wl,--rpath -Wl,/usr/lib64/openmpi/1.0.1-gcc-3.4/lib64 -lpbs /var/tmp/portage/openmpi-1.0.1/work/openmpi-1.0.1/orte/.libs/liborte.so -L/var/tmp/portage/openmpi-1.0.1/work/openmpi-1.0.1/opal/.libs /var/tmp/portage/openmpi-1.0.1/work/openmpi-1.0.1/opal/.libs/libopal.so -lm -lutil -lnsl -march=opteron -pthread -Wl,-soname -Wl,mca_pls_tm.so -o .libs/mca_pls_tm.so /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/libpbs.a(tm.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/libpbs.a: could not read symbols: Bad value /usr/lib64/libpbs.a is owned by Torque (present installed version is the sci's overlay sys-cluster/torque-2.0.0_p7.
Static libraries shouldn't need to be -fPIC, but when shared libraries link them, then they do. The preferred solution is to figure out a way to avoid linking a static library into a shared library.
I did some slight changes regarding pic behaviour on the overlay. Do you have any examples of ebuild avoiding linking static libs with shared that could save us some doc searching? right now, I simply followed http://www.open-mpi.org/faq/?category=building#build-rte
Hi New ebuild for version 1.0.2 in the overlay. Many bug fixes upstream and I added a simple warning if the threads use flag is enabled. Sebastien
(In reply to comment #4) > Hi > > New ebuild for version 1.0.2 in the overlay. Many bug fixes upstream and I > added a simple warning if the threads use flag is enabled. > > Sebastien > Thanks, I'll be testing it soon with real code ;)
In pkg_setup(), the line fortran_pkg_setup should be use fortran && fortran_pkg_setup Else, the package bombs out complaining that there is no Fortran compiler on the system...
*** Bug 129991 has been marked as a duplicate of this bug. ***
OpenMPI 1.1 is officially out, time to make an ebuild for it. Many more configure options added (sigh). Since I have some experience building that branch on Spark I'll most probably fiddle the ebuild but I'm under SUN OS (and forced to 32bit mode O_o ) so I won't be able to test the actual ebuild (ie: one constraint, arch has to be forced to v9). I will test them under x86 (P3, nocona, Athlon) and x86_64 (Opteron) though.
Created attachment 96438 [details] OpenMPI v1.1.1 ebuild This is an ebuild for v1.1.1, adapted from gentooscience.org's v1.0.2 with some addition to be able to compile using PGI compilers. Note that I patched my /etc/portage/eclass/fortran.eclass with patch from http://bugs.gentoo.org/show_bug.cgi?id=65950
I've modified the overlay's ebuild to remove the slotting because portage does not support multiple slots per version, and committed it to the tree. Thanks for your hard work and patience!
Little note: The short description should include "MPI" for -S search purposes.
