apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] apr_dso_load2() with flags support
Date Fri, 09 Sep 2005 17:12:45 GMT
Joe Orton wrote:
> 
> What's the default behaviour of the current API across all platforms?  I 
> have no idea, I expect it differs wildly from AIX to Windows and back.  
> What exactly do you propose?

AIUI (and I don't necessarily agree with these choices, but we are stuck ;-)

* Load Global.  Every platform I'm aware of will map into the symbol
   table.  Now on Win32, OS2, and OS/X (using two-level namespace) these
   symbols will be by-dso.  E.g. these three examples actually have
   multiple symbols of the same name, distinguished by the library's name.

   - disabling 'load global' is very effective for loading modules in
     parallel.  Name clashes in Linux cause dlopen to barf.  Name clashes
     on HP/UX produce 'arbitrary' results.  Better to explicitly load
     most libraries local, and then query the entry points, data or code,
     as needed.

* Bind Now, as we Run Constructors and Library Entry Points

   - disabling 'bind now' is actually a misnomer, what we are really
     saying with bind deferred, IIUC, is that we plan to only grab
     some static data or structures, and then dump the DSO without
     it ever actually performing code operations.

I think the bind now should be more abstract, to accomplish a specific
purpose.  If they choose LAZY, are the dependent libraries and symbols
resolved when the library calls them?  Consistant across platforms?
Would, say, LAZY on Linux allow the library to perform just-in-time sym
resolution, while LAZY on AIX might cause the library to crash when
trying to call an unresolved function?

As long as the goal is to produce the fewest surprises for APR users
(developers) I'll be happy with the outcome :)

Bill


Mime
View raw message