On Thu, 29 Oct 2009, Barry Smith wrote:
>
> On Oct 29, 2009, at 3:52 PM, Lisandro Dalcin wrote:
>
> > On Thu, Oct 29, 2009 at 4:45 PM, Jed Brown <jed at 59a2.org> wrote:
> > >
> > > I realize that the real problem here was OpenCV's libml and the fact
> > > that linkers don't resolve symbols by starting with the most recent -L
> > > path [*], but we should at least remember that putting -L{PETSC_LIB_DIR}
> > > at the beginning of the line can completely change the way symbols are
> > > resolved.
> > >
> >
> > 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...
> > :-)
> >
> > 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...
This works for folks who use PETSc - and nothing else. But once you
have 2 packages doing this [say both add in hypre symbols] - and then
some user wants to use these two packages - you have conflicts. [esp
with multiple copies of global variables etc..]
The ideal solution is to have every library have its own .so
file.. [but this is not easy]
Satish
