As we saw it, it was 6 of one and a half-dozen of the other.
Specifically:
- Almost everything is going to require libopal. Let's swag and say
90% of components will need libopal.
- All ORTE components will need liborte. Maybe half of OMPI components
need it (WAG).
So really, all we're talking about here are a handful of OMPI
components that don't need liborte. And *maybe* a very, very small
number of components that don't need libopal (WAG: less than 5).
So all things being equal, it was tremendously easier [and faster] to
just add all the libraries (libopal to OPAL components, liborte/opal to
ORTE components, and libmpi/orte/opal to MPI components) rather than
try to figure out exactly which ones each component needed.
So -- for the components who had an extra library linked in, who cares?
- In the static case, no additional code is linked into the component
(i.e., the component is identical to whether you linked in the
additional library or not)
- In the dynamic case, the extra library is listed in the component's
linker section. So yes, this is wasteful, but really only by a few
bytes (literally) -- and it potentially allows for faster loading at
run-time.
What exactly is the harm? It creates a small number of artificial
dependencies, but we figured it would be much safer than sorry (i.e.,
better than *not* relinking a component when it was needed).
As for why we listed all three in the MPI case (and both in the ORTE
case), it was actually to make things simpler for developers. True,
because Libtool is cool, you could just list libmpi for MPI components
(and liborte and libopal will be picked up automatically; similarly for
ORTE components), but I'll bet you $10 that most other OMPI developers
stopped reading this e-mail 5 paragraphs ago and would not spend any
cycles on why this was so, and would probably list all 3 libraries for
MPI components anyway (because that's typically how Unix linking works
-- you -l all the libraries that you need and don't rely on the linker
to automatically pick them up for you). :D
We have other things to worry about right now, and real problems to
fix. So who cares?
On Sep 23, 2005, at 12:05 PM, George Bosilca wrote:
That was the problem that trigger my question. If we remove the
dependence to the libopal in the malloc_interpose we can compile the
module. Otherwise the compilation fails because the generation of the
mca_memory_malloc_interpose happens priori to the libopal.so. However,
reading the last email I now understand why we need the backward
dependence to the libopal and liborte.
But I still see a problem. **Just to refresh the memories, I'm the
only complaining on a regular base about the useless dependencies**.
And there are a lot. I know that most of the shared libraries in ompi
use functions in the opal section. But few of them rely on any of the
orte shared libraries. If the dependencies are set correctly then we
don't have to add
$(top_ompi_builddir)/ompi/libmpi.la
$(top_ompi_builddir)/orte/liborte.la
$(top_ompi_builddir)/opal/libopal.la
all over the Makefiles.
george.
Ralf Wildenhues wrote:Andrew,
* Ralf Wildenhues wrote on Fri, Sep 23, 2005 at 10:42:34AM CEST:
* Andrew Friedley wrote on Thu, Sep 22, 2005 at 09:09:11PM CEST:
On Sep 22, 2005, at 12:56 PM, George Bosilca wrote:
Now we get this message for all .so file we generate:
libtool: install: warning: relinking `*.la'
I think I found a small error in the patch, see proposed fix below.
Cheers,
Ralf
Index: opal/mca/memory/malloc_interpose/Makefile.am
===================================================================
--- opal/mca/memory/malloc_interpose/Makefile.am (revision
7493)
+++ opal/mca/memory/malloc_interpose/Makefile.am (working copy)
@@ -22,6 +22,5 @@
libmca_memory_malloc_interpose_la_SOURCES = \
memory_malloc_interpose.c
libmca_memory_malloc_interpose_la_LIBADD = \
- $(memory_malloc_interpose_LIBS) \
- $(top_ompi_builddir)/opal/libopal.la
+ $(memory_malloc_interpose_LIBS)
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
