[petsc-dev] Fwd: [petsc-users] cannot find 'libz.a' when configuring

[Satish Balay]

On Thu, 11 Apr 2013, Matthew Knepley wrote:

> On Thu, Apr 11, 2013 at 9:48 AM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > On Thu, 11 Apr 2013, Matthew Knepley wrote:
> >
> > > On Thu, Apr 11, 2013 at 9:38 AM, Satish Balay <balay at mcs.anl.gov> wrote:
> > >
> > > > On Thu, 11 Apr 2013, Matthew Knepley wrote:
> > > >
> > > > > On Thu, Apr 11, 2013 at 9:17 AM, Satish Balay <balay at mcs.anl.gov>
> > wrote:
> > > > >
> > > > > > On Thu, 11 Apr 2013, Matthew Knepley wrote:
> > > > > >
> > > > > > > On Wed, Apr 10, 2013 at 7:53 PM, Satish Balay <balay at mcs.anl.gov
> > >
> > > > wrote:
> > > > > > >
> > > > > > > > How do we handle these packages with complicated dependencies
> > [they
> > > > > > > > are complicated as petsc dependencies?]
> > > > > > > >
> > > > > > > > In this report hdf5 was built with szip-2.1 and zlib-1.2.7. So
> > how
> > > > > > > > does petsc configure automatically detect this?
> > > > > > > >
> > > > > > > > And I've recently used the following for hdf5/necddf5 on fusion
> > > > [with
> > > > > > > > the extra implicit depenceny of hdf5 on zlib, and netcdf5 on
> > hdf5
> > > > from
> > > > > > > > within configure]
> > > > > > > >
> > > > > > > >     '--with-hdf5-lib=-L/soft/hdf5/1.8.6-parallel/lib -lhdf5_hl
> > > > -lhdf5
> > > > > > > > -lgpfs',
> > > > > > > >
> > > > > > > >     '--with-netcdf-lib=-L/soft/netcdf/4.1.1-parallel/lib
> > -lnetcdff
> > > > > > > > -lnetcdf -L/usr/kerberos/lib64 -lcurl -ldl -lgssapi_krb5 -lkrb5
> > > > > > -lk5crypto
> > > > > > > > -lcom_err -lidn -lssl -lcrypto -lz',
> > > > > > > >
> > > > > > > > Yeah - things work if the user knows the dependencies and the
> > link
> > > > > > > > command for those dependencies - and specify it to petsc
> > configure
> > > > as
> > > > > > > > above. But I'm not sure how to autodetect this.
> > > > > > > >
> > > > > > > > Also currently -lz is handled in package.py with
> > > > > > > > 'self.needsCompression' similar to 'self.needsMath' with the
> > > > detection
> > > > > > > > of -lz in libraires.py:checkCompression() - but one can't
> > specify a
> > > > > > > > --with-zlib-lib option this way. I guess this part can be
> > fixed by
> > > > > > > > migrating it a standalone package z.py. [And somehow handle the
> > > > > > > > optional part of this dependency for hdf5]
> > > > > > >
> > > > > > >
> > > > > > > We already have a mechanism for this. Lots of packages depend on
> > > > > > > other packages. This is just screwed up in the case of libz
> > because
> > > > > > > someone (maybe me) did not want to write an entire package file
> > for
> > > > > > > it, and instead copped out with the needsCompression.
> > > > > >
> > > > > > Currently we handle 'mandatory' dependencies properly - and
> > optional
> > > > > > >depencencies for --download-pakcage somewhat - but not for
> > > > > > --with-package-dir
> > > > > >
> > > > > > For hdf5 - handling just zlib.py is not sufficient. Do we add
> > szip.py,
> > > > > > zlib.py, gpfs.py [and perhaps more] for hdf5? And somehow use
> > these as
> > > > > > optionaly when testing for user provided --with-hdf5? Which package
> > > > > > currently implements this usage [to check for this optionaly
> > > > > > dependency - and give the correct error]?
> > > > > >
> > > > > > i.e In this case - when the user specified --with-hdf5-dir option.
> > We
> > > > > > had to print an error.:
> > > > > >  * please provide --with-zlib-dir and --with-szip-dir options.
> > > > > > [For a different user - with the same usage - there would be no
> > error]
> > > > > >
> > > > > > For netcdf above one would have kerbros.py, curl.py and perhaps
> > more?
> > > > >
> > > > >
> > > > > We have had this same discussion a million times, and we always
> > > > eventually
> > > > > get to the same answer and forget. Do we need our own error message
> > for
> > > > > petsc-dev?
> > > > >
> > > > > We cannot possibly guess everything that can go wrong. What we need
> > is a
> > > > > system
> > > > > where the user can specify what he actually wants and we check it.
> > So,
> > > > zlib
> > > > > and
> > > > > everything else are optional dependencies for hdf5. If something is
> > not
> > > > > specified, it
> > > > > fails, and the user goes back and specifies the right thing.
> > > >
> > > > Sure - but specify how? specify everything with
> > > > --with-hdf5-lib,--with-hdf5-include options?
> > > >
> > > > Or somehow he knows that he has to specify
> > > > --with-zlib-include/-with-zlib-lib options?
> > > >
> > >
> > > This. It would be nice if HDF5 would tell us about its dependencies, but
> > if
> > > it does not, then
> > > the user has to, and this is our system (packages).
> >
> > So we would start adding zlib.py, szip.py and manymore [and support
> > --download-zlib --download-szip]. And if user gets the error:
> >
> > --with-hdf5-dir=/foo/bar does not work.
> >
> > So he/she send us configure.log
> >
> > Then we look at it and respond saying: you need to specify --with-zlib-dir
> > --with-szip-dir options aswell.
> >
> > Does this look right?
> 
> 
> Yes, that is what I think makes sense.
> 
> We can always try to add another layer that 'greps' for libz in the hdf5
> error message and guesses that
> the user forgot it, but hopefully before we get to it, a sane storage
> library appears, or HDF5 gets its act
> together.

In this case - why bother with libz.py and szip.py? Why not tell the
user to specify hdf5 completely with --with-hdf5-include and
--with-hdf5-lib options?

Just printing the link errors on the screen might be sufficient to
clue in the user. Currently its hidden inside configure. [And its not
clear which of the 10 tests configure did for this case should be
printed on the screen as the appropriate message]

Satish