Hi Ralf, Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> Can you give a pointer to the thread? I couldn't find it easily (i.e., > within one minute :) Probably because it's inappropriately entitled. ;-) It starts here: http://lists.gnu.org/archive/html/guile-user/2005-09/msg00061.html . And I tried to summarize the issues that may be relevant to `libltdl' there: http://lists.gnu.org/archive/html/guile-user/2005-09/msg00090.html . > Erm, I may be misunderstanding, but you actually have several libcs > lying around which you choose to load from (for other libraries, I'd > understand, but libc)? This question is of course independent of your > actual request. I meant "C library" in the general sense, i.e. a library written in C, unlike in "the GNU C library". > A couple of thoughts: For one, you'd need to use the .la files to open > the modules then (with the current functions, you can also open the > plain .so or whatever it's called). This is probably not a big > constraint for your use. For another, static linking (dlpreopening) of > more than one version of the module would not work, but that is nothing > new. For Guile and other plug-in-like usage patterns, we don't really care about ``dlpreopening'': the point is precisely to load things dynamically. Aside from that, why would we need the `.la' files to open a specific version of a library? Doesn't the library file name precisely reflect its interface/revision/age? In any case, whether `libltdl' needs to read a `.la' file in order to do the job is not something the user should worry about. > Other than that, it sounds like a reasonable idea to explore post-2.0. > I believe, though, you should use INTERFACE only to decide which one to > open; the function would then search for a module where INTERFACE lies > between CURRENT-AGE and CURRENT, and try to open that. If there are > multiple matches, I'm not sure what would be best: among modules > differing only in REVISION, obviously the highest would be best. > Other than that: Assuming that, with increasing CURRENT, CURRENT-AGE > would also be non-decreasing, it should probably select the one with the > highest CURRENT, I guess. (The CURRENT comparison would obviously have > higher precedence than the REVISION comparison.) Actually, the REVISION argument is optional: implicitly, you'd always prefer the highest as you said. So we can probably remove that parameter from the function. Then I guess choosing the interface with the highest CURRENT, provided that CURRENT - AGE <= INTERFACE, things should work fine. In fact, a more fine-grained API could be exposed, something along the lines of: /* Return an array of library files that implement interface INTERFACE. */ lt_dlfile *lt_matching_dl_files (const char *filename, unsigned interface, size_t *match_count); /* Open the dynamic library represented by FILE. */ lt_dlhandle *lt_dlopen_file (lt_dlfile *file); And then, a number of accessors, like: const char *lt_dlfile_file_name (const lt_dlfile *); unsigned lt_dlfile_interface (const lt_dlfile *); unsigned lt_dlfile_age (const lt_dlfile *); unsigned lt_dlfile_revision (const lt_dlfile *); With this, users could implement any policy they like. Does this sound reasonable? Thanks, Ludovic. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
