[Pkg-openmpi-maintainers] [OMPI devel] Building with rpath disabled

[Dirk Eddelbuettel]

[ Sorry, crazy week. This was sitting in an unopened mail folder a
days. Sorry. --Dirk ]

On 13 January 2009 at 16:43, Manuel Prinz wrote:
| Am Dienstag, den 13.01.2009, 08:33 -0600 schrieb Dirk Eddelbuettel:
| > I just realized that another Debian/Ubuntu-only possibility is to use a file
| > inside /etc/ld.so.conf.d/ to make the ompi directory known to ld.so. I do so
| > for R:
| > 
| >   edd at ron:~$ cat /etc/ld.so.conf.d/libR.conf
| >   # make libR.so and libRlapack.so visible to ld.so
| >   /usr/lib/R/lib
| >   edd at ron:~$
| 
| Well, that solves an entirely different problem. It also solves a
| problem we do not have. All required libraries are found by our default
| linker configuration. We're fine.

Ok. I may just be paranoid because I as a Debian Open MPI co-maintainer now
twice had my own production use of Rmpi break because of linking issues.

Mind you, I think in one or maybe both cases was the problem with an Ubuntu
LD_FLAGS argument they set and we don't.  But I wasted so much time and
energy on that that I seem to get overly cautious.  This thread may be
entirely unrelated.
 
| The whole thing is not about any problem with our linker configuration;
| it is about problems that may arise during an rpath included in the
| binaries. We are fine because the strip rpath after building and do "The
| Right Thing (TM)" in Debian. The patch is about us (and of course)
| others to have a more convenient interface to strip rpath. We need to
| get rid of rpath to avoid problems, and if upstream's build system
| supports that, we (and maybe other distros) can get rid of some magic in
| our (Debian) build scripts.
| 
| My intention was not to solve a problem; there is none. My intention was
| to make life easier for Open MPI maintainers. If we need to maintain a
| hack forever, so be it. ;)

Ok, but what I still don't understand is this: Why do we need a patch?  

We have Debian-only issue with a Debian-only solution (strip rpath) that
works reliably.  Why change it?  And moreover, why push it upstream if it
mostly if not entirely our use case?

| > We could do the same for /usr/lib/openmpi/lib and
| > /usr/lib/openmpi/lib/openmpi.
| 
| We do not need to do that at all, as I already stated.
| 
| > That said, I generally think we should minimise difference from
| > upstream.  So my preference is still for not waking any sleeping
| > dragons ... 
| 
| ACK. But we already differ from upstream in that we remove rpath from
| the binaries, whereas binaries are build with rpath included by
| upstream's default options. All that changes is that we would remove
| rpath with upstream's build system instead of removing them in ours; we
| will (and actually do) remove rpath anyway, whether upstream supports it
| or not. I just thought it might be nicer to have the "global" solution.

Ok. 

| I'm all in favor of not breaking stuff. But I really don't see any
| dragons lying around here. Nothing really changes... But if you feel so
| strongly about that, we can just forget about the whole issue. I do not
| mind much. The patch is just for the comfort. ;)

Right.  I'm ambivalent about this. I may have overreacted on Manuel's first
email -- but that was, IIRC, not really discussed on our
pkg-openmpi-maintainers list before Manuel sent it along.

But here's a radical suggestion: How about if we put this aside (either way)
and try to focus on what may be more important.  We still have eight open
bugs, and three to four architectures on which we don't build including one
on which it used to work.

Again, my thanks to Manuel for all his Open MPI work. Sylvestre, myself and
other are not doing nearly as much.

Dirk

-- 
Three out of two people have difficulties with fractions.