Hmm. Doesn't making either the module or submodule a library fix this?
I'd choose the module if so.
Chuck
On Wednesday, August 15, 2001, at 06:00 PM, Victor J. Orlikowski wrote:
> On Wednesday, 15 Aug 2001, at 14:51:46,
> Greg Stein wrote:
>> That doesn't look right. Isn't that going to suck in the mod_dav files
>> directly into mod_dav_fs ... meaning that we'd have *two* sets of those
>> files in the process when the two modules were loaded?
>>
> You're right. This is something of a kludge.
> I did it, following Brian Havard's thinking for OS/2.
> It happens that it works... ;(
>
>> Can't you resolve symbols against an exports file of some kind? I
>> thought
>> that was why we went thru the whole export crap.
>
> In theory. However...
> I did this to both the proxy, and mod_dav. The common issue?
> Both have submodules (mod_dav_fs for mod_dav, and proxy_connect,
> proxy_ftp, and proxy_http for proxy) which are separate DSOs.
> Now, as it stands, all DSOs pull in an exports file for the main
> server.
> However, the submodules in proxy and dav require some of the functions
> within the main modules (mostly those implemented by hooks - I would die
> on proxy_hook_scheme_handler, for example).
>
> I see only one other way to clean this up - generate a separate
> exports file for any modules that have other modules depending on
> them, and tack that exports file onto the main one for the
> server. Unfortunately, I've tried this, and it doesn't work.
>
> I am open to suggestions, however.
>
> Victor
> --
> Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
> ==================================================================
> [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
>
Chuck Murcko
Topsail Group
http://www.topsail.org/
