ML symbols in petscksp.so

[Jed Brown]

Lisandro Dalcin wrote:
> I think that the real problem here is that developers should be
> smarter and they should not use such short names for a library... "ml"
> .. just two characters... What "ml" stand for? "mailing list"? the
> internet country code for Mali at Africa? "milliliter" ? "Markup
> Language", "ML" the programming language? Well... I'll stop here...

Yes, that's insane.  The name ML doesn't even appear in the associated
header file, the closest thing is a class named CvANN_MLP.  I posted
this issue on their forum so maybe they'll fix it.

> IMHO, I think that what Jed suggested in previous mail about using
> -Wl,-whole-archive ${PETSC_EXTERNAL_LIB} -Wl,-no-whole-archive when
> --with-shared is in action could be a VERY good idea... Then PETSc
> link lines will not need to refer at all to these static libs from
> external packages...

As Satish and Matt say, this can cause some trouble.  The current state
is a bit mixed in that static libs get pulled into libpetsc*.so (only
the symbols that PETSc requires), but shared libs get resolved by the
loader (with rpath).  I think putting these symbols in libpetsc*.so is
the right thing to do because only explicitly linking the interface is
normal on systems with shared libs.  With static libs, it is normal to
have to link recursive dependencies.  This is a pain in the ass when you
aren't using the upstream build system.  In particular, given the
strings A_LIBS and B_LIBS (both including recursive dependencies,
suppose there is no overlap), it's pretty much impossible to link both
portably because

  AB_LIBS = $A_LIBS $B_LIBS

will incorrectly resolve stuff in B_LIBS from paths used by something in
A_LIBS.  Some people say "your environment is broken" when this is the
case, but it's easy to end up with when the package manager puts some
stuff in /usr and you install some libs elsewhere.  The only workaround
I know is to manually resolve all the libraries in A_LIBS and B_LIBS
separately.  Unfortunately, dealing with all of this is essentially a
part of your API when using static libraries.  Bundling the symbols from
the various static libs into libpetsc*.a means that users can link the
same way and don't have to resolve recursive dependencies.


> Satish, please note that I'm talking about using --whole-archive ONLY
> with the pkgs that PETSc automatically downloads upon user requests
> using --download-<pkg> ...

Note that the current system still puts the necessary symbols from all
static libs into libpetsc*.so.  Putting them into libpetsc*.a

 (a) makes the linking API uniform, -L/path/to/petsc/lib -lpetsc*
 (b) causes a problem if they update that lib, don't update PETSc, and
     then expect their code to be calling the updated version


Jed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091029/4d270cb6/attachment.sig>