[Pkg-openmpi-maintainers] Bug#456721: Processed: Re: Bug#456721:libpetsc.so depends on unexistent libraries

Dirk Eddelbuettel edd at debian.org
Wed Dec 19 03:23:13 UTC 2007


On 19 December 2007 at 01:29, Manuel Prinz wrote:
| Am Dienstag, den 18.12.2007, 18:12 -0600 schrieb Dirk Eddelbuettel:
| > IIRC "we have no choice" as Policy mandates static builds. May be a
| > 'recommends' though.
| 
| I'm not sure about that. I didn't see that on a quick read of chapters 8
| and 10, though policy states in 10.2:
| >         Packages that use libtool to create shared libraries should
| >         include the .la files in the -dev package, unless the package
| >         relies on libtool's libltdl library, in which case the .la
| >         files must go in the run-time library package.

That's not what I had I mind. I think there was a more general recommendation
of sticking .so files,  headers files, static libraries, ... into the -dev
package. Anyway, I may well be wrong.
 
| So including the .la files was OK. The question I asked myself is
| whether we should compile the static libraries and/or (also) include
| the .la files. I have to do more reading on that one.
| 
| > On 19 December 2007 at 00:43, Manuel Prinz wrote:
| > | If noone has complaints, I will apply it to trunk.
| > Always apply, we can always fix later. No point in sending patches.
| 
| Done.

Some comments and questions:

1)  It builds fine, as before  I can build Rmpi against it. [ More on that
    below. ]

2)  I do not understand some of the file splits. Eg why 
	/usr/lib/libmca_common_sm.so.0
    Why does that need to be in /usr/lib/ and not hidden below like the other
    mca* ones ?  Ldd on the Rmpi library doesn't show it, maybe other MPI
    usage does. Do you know a case where it is needed?

3)  Links like

	libopen-rte.so.0 -> openmpi/lib/libopen-rte.so.0
        libopen-rte.so -> openmpi/lib/libopen-rte.so.0

    work but shouldn't it be

	libopen-rte.so.0 -> openmpi/lib/libopen-rte.so.0
        libopen-rte.so -> libopen-rte.so.0

    Doesn't really matter -- mere cosmetics.

4)  Should mpi.h be in /usr/include ?   I had to tell Rmpi that the main MPI
    dir is /usr/lib/openmpi/, then everythings works due to the usual
    include/ and lib/ split.

5)  Some Lintian warnings remain (but I now added two more silencers, so the
    last two should go) -- could you try and see why your man page patch
    doesn't cover'em ? 

    edd at ron:~/src/debian/SVN/build-area> lintian openmpi_1.2.4-5_i386.changes
    W: openmpi source: newer-standards-version 3.7.3 (current is 3.7.2)
    W: openmpi-doc: manpage-has-bad-whatis-entry usr/share/man/man3/MPI_Comm_f2c.3.gz
    W: openmpi-doc: manpage-has-bad-whatis-entry usr/share/man/man3/MPI_Status_f2c.3.gz
    W: libopenmpi1: postinst-has-useless-call-to-ldconfig
    W: libopenmpi1: postrm-has-useless-call-to-ldconfig

6)  The main thing is: It works:

    > library(Rmpi)
    > library(snow)
    > nbClusters <- 3
    > cl <- makeCluster(nbClusters, "MPI")
	3 slaves are spawned successfully. 0 failed.
    > clusterCall(cl, function() Sys.info()[c("nodename","machine")])
    [[1]]
    nodename  machine 
       "ron"   "i686" 

    [[2]]
    nodename  machine 
       "ron"   "i686" 

    [[3]]
    nodename  machine 
       "ron"   "i686" 

   
So I'd be happy to build and submit this as is.  In fact, I think I will
given how we have open bugs against it.  The rest can be cleaned up later,

Dirk

 
| > I'll try to build this later to see where I'm at w.r.t. my Rmpi breakage.
| > 
| > Thanks for all your work,  Dirk
| 
| You're welcome! Besides that, I was the one who broke it in the first
| place. ;)
| 
| Best regards
| Manuel

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






More information about the Pkg-openmpi-maintainers mailing list