On Sep 7, 2010, at 9:35 AM, Nick Mathewson wrote: > Hi, Ralph! > > On Tue, Sep 7, 2010 at 11:04 AM, Ralph Castain <r...@open-mpi.org> wrote: > [...] >> (b) we need to modify it somewhat to get things working correctly across the >> broad range of our installed base. > > Any chances of getting the patches here upstreamed? "Working > correctly across a broad install base" sounds like a feature worth > merging into the main distribution. ;)
I'm still working through what was done, but will certainly pass them along as I decipher them. From what I see, they are mostly centered around things like epoll not working quite the way you expected on certain platforms (so we have to ensure that mode doesn't get used there), etc. I don't see where people tried to solve the problem, but more tried to ensure it was avoided. :-/ > >> It is my understanding that quite a few software packages also embed >> libevent in their distributions, so this is a fairly common problem. It >> would make life much easier, therefore, if you only declared the true public >> APIs as public symbols, defining all internal-only functions as "static". > > Pretty much every symbol that's used only in a single module *is* > declared static right now. (If we missed some, that's worth fixing: > just send in a patch.) The remaining non-static symbols are ones > shared between modules, and of course C doesn't let you make those > static. The right solution here is probably to manually tell the > linker about what symbols to export and what symbols not to export. > On windows, this is the dllexport/dllimport stuff stuff. With gcc4 on > other platforms, this is the __attribute__((visibility(...))) stuff. > ( http://gcc.gnu.org/wiki/Visibility ) > > I'd like to move this way in Libevent 2.1, but I'm not sure on the > timeframe, since it's a fair amount of work. If somebody commits to > writing up and testing the code here, that'll improve the odds of it > getting done. I agree - it's basically a visibility issue. I could certainly test for you, and can try to get to the coding part as time permits. Cheers Ralph > > peace, > -- > Nick > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
