You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2001/08/15 23:51:46 UTC
Re: cvs commit: httpd-2.0/modules/dav/fs config6.m4
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?
Can't you resolve symbols against an exports file of some kind? I thought
that was why we went thru the whole export crap.
Cheers,
-g
On Wed, Aug 15, 2001 at 06:14:51PM -0000, orlikowski@apache.org wrote:
> orlikowski 01/08/15 11:14:51
>
> Modified: modules/dav/fs config6.m4
> Log:
> Works under AIX as a DSO now.
>
> Revision Changes Path
> 1.7 +4 -0 httpd-2.0/modules/dav/fs/config6.m4
>
> Index: config6.m4
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/dav/fs/config6.m4,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -u -r1.6 -r1.7
> --- config6.m4 2001/08/14 12:15:04 1.6
> +++ config6.m4 2001/08/15 18:14:51 1.7
> @@ -11,6 +11,10 @@
> fi
>
> case "$host" in
> + *-ibm-aix*)
> + # AIX wants the symbols resolved, but doesn't like .la files ... ;(
> + dav_fs_objects="$dav_fs_objects ../main/mod_dav.lo ../main/props.lo ../main/util.lo ../main/util_lock.lo ../main/liveprop.lo ../main/providers.lo ../main/std_liveprop.lo"
> + ;;
> *os2*)
> # OS/2 DLLs must resolve all symbols at build time
> # and we need some from main DAV module
>
>
>
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/dav/fs config6.m4
Posted by "Victor J. Orlikowski" <v....@gte.net>.
On Thursday, 16 Aug 2001, at 12:22:27,
Brian Havard wrote:
> For OS/2 I have aplibtool generate an import library for each shared
> library it links which is what it uses when you specify the .la. So what
> I've done makes mod_dav_fs link against mod_dav's import library, not its
> actual object files.
Ah! I wondered why using the .la file on AIX didn't work directly.
Hrm.
I'll attempt something similar for AIX then, if trying to generate
(yet) another exports doesn't turn the trick...
Victor
--
Victor J. Orlikowski | The Wall is Down, But the Threat Remains!
==================================================================
v.j.orlikowski@gte.net | orlikowski@apache.org | vjo@us.ibm.com
Re: cvs commit: httpd-2.0/modules/dav/fs config6.m4
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Wed, 15 Aug 2001 18:00:26 -0400, 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.
For OS/2 I have aplibtool generate an import library for each shared
library it links which is what it uses when you specify the .la. So what
I've done makes mod_dav_fs link against mod_dav's import library, not its
actual object files.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/modules/dav/fs config6.m4
Posted by Chuck Murcko <ch...@topsail.org>.
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!
> ==================================================================
> v.j.orlikowski@gte.net | orlikowski@apache.org | vjo@us.ibm.com
>
Chuck Murcko
Topsail Group
http://www.topsail.org/
Re: cvs commit: httpd-2.0/modules/dav/fs config6.m4
Posted by "Victor J. Orlikowski" <v....@gte.net>.
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!
==================================================================
v.j.orlikowski@gte.net | orlikowski@apache.org | vjo@us.ibm.com