Bug#588334: RFH: petsc
Adam C Powell IV
hazelsct at debian.org
Wed Jul 14 14:22:15 UTC 2010
On Mon, 2010-07-12 at 18:32 -0400, Adam C Powell IV wrote:
> On Mon, 2010-07-12 at 23:11 +0200, Johannes Ring wrote:
> > Hi Adam,
> > On Wed, Jul 7, 2010 at 5:51 PM, Adam C Powell IV <hazelsct at debian.org> wrote:
> > > Hello,
> > >
> > > I'm having two problems with PETSc, and need some help.
> > >
> > > Second, I just uploaded a new version, and although the build process
> > > reports that it builds the libraries just fine, they are not installed
> > > during the install step -- though on my machine it all works fine. This
> > > seems odd to me, as "install" is just a matter of copying everything:
> > >
> > > cp -a linux-gnu-c-opt/lib debian/libpetsc3.1-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/
> > >
> > > The linux-gnu-c-opt/lib directory is PETSC_LIB_DIR, but it must be
> > > empty, because the corresponding directory in the package is empty.
> > >
> > > Can someone else try to build it, and let me know what's in the
> > > linux-gnu-c-opt/lib directory at the end?
> > I built PETSc in pbuilder and this is the contents in the
> > linux-gnu-c-opt/lib folder:
> > # ls -lh linux-gnu-c-opt/lib/
> > total 19M
> > -rw-r--r-- 1 root root 13M Jul 12 20:33 libpetsc.a
> > -rwxr-xr-x 1 root root 6.0M Jul 12 20:33 libpetsc.so
> Thanks very much Johannes.
> I'm consistently getting:
> % ls -lh linux-gnu-c-opt/lib/
> total 19M
> -rw-r--r-- 1 hazelsct 1003 13M 2010-07-06 23:39 libpetsc.a
> lrwxrwxrwx 1 hazelsct 1003 15 2010-07-06 23:39 libpetsc.so -> libpetsc.so.3.1*
> -rwxr-xr-x 1 hazelsct 1003 6.0M 2010-07-06 23:39 libpetsc.so.3.1*
> The install step should be putting all of these into
> debian/libpetsc-dev/usr/lib/petscdir/3.1/linux-gnu-c-opt/lib but for
> some reason the buildds are not getting the libpetsc.a or the .so
> symlink, let alone the name-versioned lib...
> Okay, you've given me some ideas, now back to the drawing board.
D'oh, I'm an idiot! There's no patch target in PETSc's debian/rules.
I'll try that, so the patches actually apply on the buildds. Yup,
buildd logs show that the clean target removes all the patches, then it
goes ahead and builds without re-applying them.
That should also get rid of rpath in environment variables, closing
Fixing that right now and uploading...
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 190 bytes
Desc: This is a digitally signed message part
More information about the debian-science-maintainers