Bugzilla Bug 126295

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 an attachment (id=96438) [edit]
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.