On Mon, Dec 17, 2007 at 03:13:06PM -0500, Jeff Squyres <[EMAIL PROTECTED]> wrote: > > From what I recall, libev is embeddable and has instructions to do > > such... > > I didn't see support for the things I mentioned...?
You must suffer form extreme blindness. The documentation is linked from about each and every release announcement, and from the homepage, is part of every package (and comprises the installed manpage for ev), and contains a top-level section named "EMBEDDING". If you didn't find it, you didn't look, sorry... > 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> ... When embedding, you are responsible for the configure script. > > 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" Huh??? libev# grep ^static *.c|wc -l 54 and this doesn't event count the functions where static is part of the inline_xxx macros. > difficult to call libev functions ;-) ), and therefore they are global > to the entire process who links against libev. Thats not true, all systems supporting shared libraries support (and use) namespace compartments. A non-static symbol linked statically into your library will not conflict with any dynamically-linked in ones and vice versa. > applications link against. What if Open MPI has an embedded copy of > libev version X, but the system has libev version Y installed? 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). And in any case, this is easy enough to do yourself (]define is cheap) if you don't want to take the right approach :) > application links against both Open MPI (and it's embedded libev > version X) *and* the system-installed libev, we have a conflict. Only in some cases, not in the general case, no. > 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. Renaming of exported symbols will not help there, though, so this example doesn't apply. If you need to export libev to your library users publicly, then you cannot install into the same prefix and/or need to rename the installed header files yourself. libev certainly supports both. But most likely, when you embed, you have little need to expose the libev API. > 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. Only if open mpi does something very stupid, such as overwriting an existing libev when there is npo need to do so. In ym opinion, open mpi shouldn't do that when embedding, and in any case, if openmpi insists on installing their own libev shared library, its openmpi who screws up majorly and needs to rename the installed library... libev certainly doesn't dictate that you build a shared library. > 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. How about embedding libev? :) > What do the other projects that embed libev do about these kinds of > issues? They don't have those issues as they simply embed libev. When it becomes a shared library, this is not a problem due to the namespace resolution rules. And in any case, this is all the responsibility of openmpi, the embedder, as libev has no control over configure scripts or library names in that scenario. I suggest reading the documentation (the "EMBEDDING" section, and if you cannot find it, its here: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#EMBEDDING). And then maybe study some of the existing projects that embed libev (most currently known are mentioned in the documentation, too). -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
