This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 05 Nov 2013 03:37:10 +0000
- Subject: [Bug dynamic-link/11767] RFE: dlopen of in-memory ET_DYN or ET_EXEC object
- Auto-submitted: auto-generated
- References: <bug-11767-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=11767
--- Comment #19 from Rich Felker <bugdal at aerifal dot cx> ---
It's already possible: you write into a temp file and call dlopen on the temp
file. What you're asking for is not "making simple things easy and complex
things possible" but rather "making simple things complex as a dubious
premature optimization".
As for your proposed Lisp implementation usage case, it's probably a bad idea.
Even aside from the issue of avoiding symbol clashes with the C namespace
(which you could avoid with prefixing of some sort, at the cost of added
hashing/lookup cost), dlsym is simply not very efficient. POSIX requires it to
accept invalid DSO handles (which glibc currently does not tolerate; see bug
#14989) and report an error rather than crashing, which adds a good deal of
otherwise-unnecessary overhead. I'm also unclear on how lookup time and space
requirements scale with number of DSOs loaded (of which you may have a lot).
But even if not for all these issues, it's just bad design to write one thing
that depends on the implementation internals of another.
--
You are receiving this mail because:
You are on the CC list for the bug.