On Dec 17, 2007, at 2:31 PM, Thomas Harning wrote:
> From what I recall, libev is embeddable and has instructions to do
> such...
I didn't see support for the things I mentioned...?
> As for prefixing symbols... gcc is capable of doing that.. I think..
Open MPI supports many more compilers than just gcc. :-)
Specifically: a simple set of configure-generated #defines to rename
all public symbols would be sufficient. These can all be localized to
a single .h file for ease of continued maintenance. E.g.:
./configure --with-embed-symbol-prefix=<foo> ...
Or something like that.
> If you statically link it in and don't export the symbols.. then you
> shouldn't even have to worry about prefixes since they become
> "invisible"....
How so?
None of libev's symbols are "static" (which would kinda make it
difficult to call libev functions ;-) ), and therefore they are global
to the entire process who links against libev.
My concern is that Open MPI is middleware -- it's a library that
applications link against. What if Open MPI has an embedded copy of
libev version X, but the system has libev version Y installed? If an
application links against both Open MPI (and it's embedded libev
version X) *and* the system-installed libev, we have a conflict.
Nothing good can happen there.
Here's another scenario: libev version X is embedded in Open MPI, but
libev version Y is *already installed* on the system. If Open MPI is
installed with the current libev embedded into the same $prefix as the
existing libev, libev.so (and ev.h and friends) will be overwritten.
This could break other apps on the system that were using the already-
installed libev. Similarly, if a new libev is installed after Open
MPI is installed, it could break Open MPI.
There needs to be a way to clearly delineate between an embedded
version of libev and another, external libev that is also used in the
same process. That was my motivation for listing the items in my
first e-mail.
What do the other projects that embed libev do about these kinds of
issues?
--
Jeff Squyres
Cisco Systems
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
