ML symbols in petscksp.so
Satish Balay wrote: I don't see any changes in the 'shared' target for linux [in conf/rules] And I just did a build with current petsc-dev - and see a bunch of ML_ symbols Thanks Satish. Wiping externalpackages and PETSC_ARCH was enough. It just didn't work when I only wiped the ML-related stuff and reconfigured. I'm not sure what I missed, but sorry for the confusion. 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/20091028/18640393/attachment.pgp
ML symbols in petscksp.so
Jed Brown wrote:
Jed Brown wrote:
Satish Balay wrote:
I don't see any changes in the 'shared' target for linux [in conf/rules]
And I just did a build with current petsc-dev - and see a bunch of ML_
symbols
Thanks Satish. Wiping externalpackages and PETSC_ARCH was enough.
I spoke too soon.
Okay, my problem was that a completely different package (OpenCV, a
dependency for something else) installed a libml in /usr/lib, the timing
was just coincidental. Since I keep some libraries in /usr (like
parmetis and hdf5), -L/usr/lib came before -L${PETSC_LIB_DIR} in
PACKAGES_LIBS, therefore the wrong libml was linked in shared_linux.
OTOH, the correct one was linked for the examples because
-L${PETSC_LIB_DIR} was prepended to the link line. The complete story
follows, in case someone else runs into this issue.
So I had
/usr/lib/libml.so (opencv)
$PETSC_DIR/$PETSC_ARCH/lib/libml.a ($PETSC_LIB_DIR/libml.a)
The link for shared_arch is effectively
-L/usr/lib -L${PETSC_LIB_DIR} -lml
which brings in /usr/lib/libml.so which doesn't resolve anything, but
the linker doesn't complain about unresolved symbols because it was
building a shared library. Now we might expect an example to actually
fail over this, but that is linked with
-L{PETSC_LIB_DIR} -lpetsc* ${PETSC_EXTERNAL_LIB_BASIC}
so this time it is resolved to the correct $PETSC_LIB_DIR/libml.a.
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.
Jed
[*] I find PETSc link lines to be slightly deceptive. They often look
like
-L/A -rpath=/A -lA -L/B -rpath=/B -lB
with the implication that it would resolve to /A/libA.a /B/libB.a, but
the linker will find /A/libB.a if it exists.
-- 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/a899b7e8/attachment.pgp
ML symbols in petscksp.so
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...
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
ML symbols in petscksp.so
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...
Agreed.
Barry
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
ML symbols in petscksp.so
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
ML symbols in petscksp.so
On Thu, Oct 29, 2009 at 4:01 PM, Satish Balay balay at mcs.anl.gov wrote:
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]
I am with Satish here. This smells like sticking pregenerated template stuff
in libraries,
which eventually gets heinous, and everyone always goes back to all headers.
I am
for keeping each package in its own libraries.
Matt
Satish
--
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091029/5d58c8da/attachment.html
ML symbols in petscksp.so
On Thu, Oct 29, 2009 at 7:01 PM, Satish Balay balay at mcs.anl.gov wrote:
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..]
And can you explain me how the current situation is better? Let's
suppose other self-contained beast like PETSc also builds a static
hypre lib... then when you mix stuff, you have two libhypre.a at
different places... Then you link your program... and the linker will
likely pick one... which one? whatever... All this works by accident,
I think...
So I still think that for petsc-downloaded external packages built as
static libs, the -W,-whole-archive should be used... If this is not
what users want, then they should previously build these ext packages
themselves and pass info to configure.py... After all, when I ask
PETSc to download a pkg is because I do not have it built/installed...
for example, I never petsc-download blas/lapack because I have them in
my boxes... The same applies with MPI, I've never --download-mpi...
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 ...
The ideal solution is to have every library have its own .so
file.. [but this is not easy]
Satish
Yes... Perhaps it is not that hard...
--
Lisandro Dalc?n
---
Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
PTLC - G?emes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
ML symbols in petscksp.so
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.pgp
ML symbols in petscksp.so
Something recently caused these symbols to get lost, meaning that users have to explicitly link the static libml.a. 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/20091028/6d8e3fbb/attachment.pgp
ML symbols in petscksp.so
You always have to link the ML library if you configure for ML, right? Matt On Wed, Oct 28, 2009 at 3:34 PM, Jed Brown jed at 59a2.org wrote: Something recently caused these symbols to get lost, meaning that users have to explicitly link the static libml.a. Jed -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/12013374/attachment.html
ML symbols in petscksp.so
On Wed, Oct 28, 2009 at 4:14 PM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: You always have to link the ML library if you configure for ML, right? No, all the third party libs used to be put into the PETSc shared libs (but not the static libs). The easiest way to do this is with -Wl,--whole-archive though I haven't looked at the build system to see if this is how it is actually being done. All the others still behave this way, but ML is no longer included. Wenever did this, and satill don't. We use -rpath, so that you can track back to the associated shared library, if it exists. Matt So if you are using shared libs, you only need to link libpetsc*.so. This is recommended practice with shared libs, you only explicitly link the interface libraries (those that your code actually calls into) and let the linker handle the dependencies. Of course when using static libs, you need to explicitly link all the dependencies. Jed -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/d42e85c7/attachment.html
ML symbols in petscksp.so
We do do this for Mac (libpetsc*.dylib) and I think it mostly works. But I am not aware of anyone doing this intentionally for PETSc on Linux (though I think it is a good idea if it can be done). Bartry On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote: On Wed, Oct 28, 2009 at 4:14 PM, Jed Brown jed at 59a2.org wrote: Matthew Knepley wrote: You always have to link the ML library if you configure for ML, right? No, all the third party libs used to be put into the PETSc shared libs (but not the static libs). The easiest way to do this is with -Wl,--whole-archive though I haven't looked at the build system to see if this is how it is actually being done. All the others still behave this way, but ML is no longer included. Wenever did this, and satill don't. We use -rpath, so that you can track back to the associated shared library, if it exists. Matt So if you are using shared libs, you only need to link libpetsc*.so. This is recommended practice with shared libs, you only explicitly link the interface libraries (those that your code actually calls into) and let the linker handle the dependencies. Of course when using static libs, you need to explicitly link all the dependencies. Jed -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
ML symbols in petscksp.so
Barry Smith wrote: We do do this for Mac (libpetsc*.dylib) and I think it mostly works. But I am not aware of anyone doing this intentionally for PETSc on Linux (though I think it is a good idea if it can be done). It has been working for more than a year on Linux. If you still have a --with-shared build from last week, run $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_ # I have over 800 symbols I still have all the symbols from HYPRE, Sundials, MUMPS, etc. Only ML was broken in the last few days. On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote: Wenever did this, and satill don't. We use -rpath, so that you can track back to the associated shared library, if it exists. Use of RPATH is orthogonal to this, --download-* builds static libs which get bundled into libpetsc*.so. 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/20091028/f2f072b5/attachment.pgp
ML symbols in petscksp.so
On Oct 28, 2009, at 4:37 PM, Jed Brown wrote: Barry Smith wrote: We do do this for Mac (libpetsc*.dylib) and I think it mostly works. But I am not aware of anyone doing this intentionally for PETSc on Linux (though I think it is a good idea if it can be done). It has been working for more than a year on Linux. If you still have a --with-shared build from last week, run $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_ # I have over 800 symbols I never said it didn't work. I just said we didn't intentionally set it up this way. Since Matt and I are not aware of this feature than whoever did set it up (or you) have to figure out why it changed for ML. Also I said I like it. Barry I still have all the symbols from HYPRE, Sundials, MUMPS, etc. Only ML was broken in the last few days. On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote: Wenever did this, and satill don't. We use -rpath, so that you can track back to the associated shared library, if it exists. Use of RPATH is orthogonal to this, --download-* builds static libs which get bundled into libpetsc*.so. Jed
ML symbols in petscksp.so
On Wed, 28 Oct 2009, Jed Brown wrote: Barry Smith wrote: We do do this for Mac (libpetsc*.dylib) and I think it mostly works. But I am not aware of anyone doing this intentionally for PETSc on Linux (though I think it is a good idea if it can be done). It has been working for more than a year on Linux. If you still have a --with-shared build from last week, run $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_ # I have over 800 symbols I still have all the symbols from HYPRE, Sundials, MUMPS, etc. Only ML was broken in the last few days. I don't see any changes in the 'shared' target for linux [in conf/rules] And I just did a build with current petsc-dev - and see a bunch of ML_ symbols ./configure --with-mpi-dir=/home/petsc/soft/linux-Ubuntu_8.04-ia32/mpich2-1.0.8p1-gcc431 --download-ml=1 PETSC_ARCH=arch-linux-ml --with-shared=1 make PETSC_ARCH=arch-linux-ml [petsc:petsc-dev/arch-linux-ml/lib] petsc nm -Ao *.so | grep ML_ | grep ' T ' | wc -l 820 [petsc:petsc-dev/arch-linux-ml/lib] petsc Satish
