On Wed, Sep 21, 2005 at 10:50:33AM -0500, William Rowe wrote: > Joe Orton wrote: > > > >>Can you define a few problems you want to solve, and we will map them > >>to appropriate combinations of flags, and determine if they can be > >>1) supported, 2) ignored, 3) not implemented across our platforms? > > > >I want to be able to load DSOs with RTLD_LOCAL to prevent population of > >the global symbol table and I want to be able to loads DSOs with > > RTLD_DEEPBIND to work around namespace collisions between libraries on > > which said DSOs depend. > > Very cool! Ok, one down, we define APR_DSO_PRIVATE as one of the flags, > which would mean local, and run the initializers (cpp constructors) to > make the module usable. If RTLD_DEEPBIND is autoconf-detected, it can > be added to the RTLD_LOCAL flag.
RTLD_DEEPBIND is orthogonal to RTLD_LOCAL. > A second option, APR_DSO_STATIC, could have the same 'local' scope, > however it would be used to load a module without initializers (on any > platform which supports this) to simply query the data within the dso, > e.g. if we wanted to look up the module_foo structure members in httpd. > I'm not suggesting we do this now (unless someone asks), but we should > distinguish between the two behaviors upfront. This flavor, on other > platforms, could choose any sort of 'delayload' flag to further ensure > we don't drag in subdependencies. > > Does this make sense? Not really, too vague, I have no idea why the distinction between APR_DSO_STATIC and APR_DSO_LOCAL is useful nor why you are bringing up C++ initializers. If you want to propose an alternative interface please do it in full in "diff -u" format, otherwise please give a technical justification for your veto on what I proposed which makes more sense than "It must not expose special platform knowledge". Regards, joe
