I'll reply just to this last message in the thread: yes, I totally
bozoed and missed the documentation. I read the README, Makefile.am,
and ev.h, but somehow totally missed libev.m4. Shame on me for
missing the obvious documentation.
Having now RTFM'ed, I still have a few of my original questions, but
stated hopefully *without* all the typos and inaccuracies from my
previous posts that made me look like a total idiot (note to self: do
not type of technical e-mails while on a teleconference)...
1. My bias/assumed definition for "embedding" was to a) include the
entire libev tarball in Open MPI (via Subversion's 3rd party/vendor
import conventions), b) have our configure call your m4 macros, and c)
have an upper-level Makefile.am traverse into the libev directory and
use your Makefile.am. It was from this context that I was asking
about renaming the library to lib<foo>ev.la and/or not installing it.
1a. You seem to indicate that you only want the *source* to be
embedded, but not the distributed Makefile.am. However, your docs say:
"The goal is to enable you to just copy the neecssary files into your
source directory without having to change even a single line in them,
so you can easily upgrade by simply copying (or having a checked-out
copy of libev somewhere in your source tree)."
In this case, having an expanded tarball in our tree is "close enough"
to having a checked-out copy of libev. As such, it would be desirable
to just be able to descend into the libev directory via a SUBDIRS
entry in an upper-level Makefile.am and use your Makefile.am without
modification. Meaning that it must be possible to either change the
output library name and/or make it a noinst/convenience LT library.
noinst is preferable for the reasons you already cited (I would prefer
not to install it, but rather include/embed it in our own library --
this is what we do with libevent today).
1b. Along the same lines, if we don't want to modify the libev source
at all, we can't supply all the #define's to rename the public symbols
without additional source wrappers. I agree that #defines are cheap
and the right way to go, but if we're literally just compiling your
source (such as via an expanded libev tarball or a libev checkout in
our tree), we'd either have to provide additional libev source
wrappers or modify your source to insert those #define's (and keep up
with them as the libev API grows/changes). It would be preferable to
keep the libev/ directory be 100% libev source and not have to provide
any source wrappers.
In summary, the following two changes would be most helpful:
- an m4 macro to change the output library to be noinst
- an m4 macro to change (prefix?) all the public symbols in the output
library
Are these changes possible? They would be most helpful to middleware
that wants to embed libev: they allow us to safely link in the
generated libev library to our library, and keep the libev/ library
completely "pure" -- no modifications and no source wrappers. This
will definitely help maintenance over time. Or are these changes
contrary to your definition / philosophy of embedding?
2. Static: per the note above (being distracted while typing technical
e-mails), I wasn't clear what I meant - sorry. What I meant was that
libev's *public* symbols are not static. And since they're not, there
*can* be symbol conflicts between an embedded libev and a non-embedded
one. The gcc example I gave was also borked; what I meant was:
gcc my_app.c -lmpi -lev -o my_app
In this example, without #define's to rename all the public symbols in
libmpi, my_app.c will get the system-installed ev.h (that matches the
API in -lev), but will actually link against the ev symbols in libmpi
due to linker left-to-right resolution. If the libev versions are
different between the two, Bad Things could happen (to potentially
include duplicate symbols -- e.g., if my_app.c uses a new symbol that
exists in -lev but not in -lmpi, it will pull in the necessary .o file
from -lev, but this may contain some of the same public symbols as -
lmpi).
This is why I was asking for built-in support for renaming the public
symbols (e.g., via an m4 macro to trigger a bunch of #define's -- I
gave a ./configure example without any context or explanation).
2a. However, you made a comment in one of your replies that I didn't
fully understand:
-----
JMS: What if Open MPI has an embedded copy of libev version X, but the
system has libev version Y installed?
ML: Then the right approach is not to embed, as there can only be one
event loop in a process, as an event loop needs to take control of the
process (ot thread).
-----
What do you mean that there can only be one event loop in a process /
an event loop needs to "take control" of the process? What does "take
control" mean? If all the symbols are separate (e.g., via #define's),
is there a reason that two libev's can't co-exist in the same process?
My goal would be that the libev embedded in Open MPI would be 100%
private -- what we do in our event loop should not affect what the
application does with its event loop (and vice versa, obviously).
------
Hopefully, this is much more clear than my original posts...
Thanks.
On Dec 17, 2007, at 5:34 PM, Marc Lehmann wrote:
> On Mon, Dec 17, 2007 at 10:56:05PM +0100, Marc Lehmann <[EMAIL PROTECTED]
> > wrote:
>>> string, preferably via an argument to the configure M4 macro
>>
>> All public symbols are already prefixed with ev_ and there are no
>> public
>> symbols except as required by the API. If you need to rename some
>> symbols
>> it is easy enough to do so yourself with a simple #define.
>
> In the light of the following discussion, let me elaborate this
> more, to
> avoid the obvious question:
>
> unlike libevent, which exports almost all of its
> functions, including the internal ones (e.g.
> http://ue.tst.eu/95cc821336a4aab78072252c587acb05.txt),
> libev ONLY exports truely public symbols (see here,
> http://ue.tst.eu/eaffbcc456fe160ff44f462e8cf9694a.txt, this is the
> *full*
> list of exported symbols for the current release). You can get rid
> of the
> event_ ones if you don't use the libevent emulation, too.
>
> That means that there is no need to rename symbols internally, as
> internal
> symbols are not visible. If you feel the need to rename external
> symbols
> you can easily do so yourself (this isn't, in general, required when
> embedding libev, though).
>
> In any case that means that openmpi already suffers from any such
> probelms
> and seems to cope well, too. It certainly will become much easier
> with libev.
>
> --
> The choice of a Deliantra, the free code
> +content MORPG
> -----==- _GNU_ http://www.deliantra.net
> ----==-- _ generation
> ---==---(_)__ __ ____ __ Marc Lehmann
> --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
> -=====/_/_//_/\_,_/ /_/\_\
--
Jeff Squyres
Cisco Systems
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
