You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/11/17 00:57:44 UTC
exports.c again
After committing the AIX exports file patch today, I get much
breakage:
. Solaris and Tru64 die because they don't have apr_sendfile().
. Everything dies (I guess) when built without threads because there is
no apr_get_os_thread() and apr_get_os_threadkey().
Ryan said before that we need dummy versions of these functions. O.k.
But we don't even have declarations for these unless APR_HAS_THREADS
and APR_HAS_SENDFILE is defined.
Rather than doing #include on all the files in apr/include, I'd rather
exports.c have kludged-up declarations for everything. Then we don't
have to expose apr_sendfile() in the header file if APR_HAS_SENDFILE
isn't defined (and same for other function).
So we'd first spit out
extern const void *apr_MD5Encode;
extern const void *apr_MD5Final;
extern const void *apr_MD5Init;
then
const void *ap_hack_apr_MD5Encode = (const void *)apr_MD5Encode;
const void *ap_hack_apr_MD5Final = (const void *)apr_MD5Final;
const void *ap_hack_apr_MD5Init = (const void *)apr_MD5Init;
Alternatively, we can declare all possible functions in the apr header
files regardless of the configuration.
Any preferences?
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: exports.c again
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 16, 2000 at 06:57:44PM -0500, Jeff Trawick wrote:
>...
> Alternatively, we can declare all possible functions in the apr header
> files regardless of the configuration.
>
> Any preferences?
We don't really want to have the declarations if the functions are not
available. If APR users attempt to use the functions without checking for
the availability, then they'll get a compile error rather than a link error.
When we have APR as a shared lib, then avoiding the load-time error will be
a big win.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: exports.c again
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 16, 2000 at 05:08:09PM -0800, rbb@covalent.net wrote:
>...
> Yes. While you are on this problem, can you think of a better solution
> than the ugly hack? The other option that I had thought of, was to define
> a global variable in each C file, and just refer to that variable ion the
> exports.c. This would take slightly more time to generate, and it would
> pollute APR with Apache specific stuff, but it would probably be more
> portable.
It would be nice to avoid doing that so we can keep the size of the globals
as small as possible. Maybe not a big deal, but I'd rather we resolve the
problem through link-time mechanisms than to monkey up APR.
(note that APR as a shared lib would solve this issue)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: exports.c again
Posted by rb...@covalent.net.
> The variable per file could be a solution. If the variable
> declaration in each file used a macro it would be easy for a script to
> find it.
>
> The fix tonight was a little more complicated than I thought... there
> were a bunch of unresolved thread functions.
>
> We can see how the current mechanism works for a while. We've been
> tweaking the exports.c mechanism for a couple of weeks now... maybe
> required changes will become more infrequent. Maybe not :(
Granted, this whole thing is a hack, but the current solution just feels
like a very large hack. :-(
Oh well.....
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: exports.c again
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> Yes. While you are on this problem, can you think of a better solution
> than the ugly hack? The other option that I had thought of, was to define
> a global variable in each C file, and just refer to that variable ion the
> exports.c. This would take slightly more time to generate, and it would
> pollute APR with Apache specific stuff, but it would probably be more
> portable.
The variable per file could be a solution. If the variable
declaration in each file used a macro it would be easy for a script to
find it.
The fix tonight was a little more complicated than I thought... there
were a bunch of unresolved thread functions.
We can see how the current mechanism works for a while. We've been
tweaking the exports.c mechanism for a couple of weeks now... maybe
required changes will become more infrequent. Maybe not :(
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: exports.c again
Posted by rb...@covalent.net.
> > I like not needing the declarations regardless of the config. In other
> > words exports.c should declare the functions.
> >
> > This should be VERY easy to add to the script that generates the
> > code. Question though. Won't AIX get messed up if there are functions in
> > httpd.exp that aren't defined?
>
> As I understand it,yes, AIX will get messed up if httpd.exp has
> functions which aren't defined.
>
> What I plan to do when I get a chance (a few hours from now?):
>
> 1) change buildexports.sh to first spit out declarations (instead of
> #include-s), then spit out what it does now
>
> 2) add APR_ENOTIMPL versions of apr_sendfile(), apr_get_os_thread(),
> and apr_get_os_threadkey()
>
> In the future we can expect to add a few more dummy functions (like
> David Reid's problem with the procattr function on BeOS).
>
> Are we on the same page?
Yes. While you are on this problem, can you think of a better solution
than the ugly hack? The other option that I had thought of, was to define
a global variable in each C file, and just refer to that variable ion the
exports.c. This would take slightly more time to generate, and it would
pollute APR with Apache specific stuff, but it would probably be more
portable.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: exports.c again
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > So we'd first spit out
> >
> > extern const void *apr_MD5Encode;
> > extern const void *apr_MD5Final;
> > extern const void *apr_MD5Init;
> >
> > then
> >
> > const void *ap_hack_apr_MD5Encode = (const void *)apr_MD5Encode;
> > const void *ap_hack_apr_MD5Final = (const void *)apr_MD5Final;
> > const void *ap_hack_apr_MD5Init = (const void *)apr_MD5Init;
> >
> > Alternatively, we can declare all possible functions in the apr header
> > files regardless of the configuration.
> >
> > Any preferences?
>
> I like not needing the declarations regardless of the config. In other
> words exports.c should declare the functions.
>
> This should be VERY easy to add to the script that generates the
> code. Question though. Won't AIX get messed up if there are functions in
> httpd.exp that aren't defined?
As I understand it,yes, AIX will get messed up if httpd.exp has
functions which aren't defined.
What I plan to do when I get a chance (a few hours from now?):
1) change buildexports.sh to first spit out declarations (instead of
#include-s), then spit out what it does now
2) add APR_ENOTIMPL versions of apr_sendfile(), apr_get_os_thread(),
and apr_get_os_threadkey()
In the future we can expect to add a few more dummy functions (like
David Reid's problem with the procattr function on BeOS).
Are we on the same page?
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: exports.c again
Posted by rb...@covalent.net.
> So we'd first spit out
>
> extern const void *apr_MD5Encode;
> extern const void *apr_MD5Final;
> extern const void *apr_MD5Init;
>
> then
>
> const void *ap_hack_apr_MD5Encode = (const void *)apr_MD5Encode;
> const void *ap_hack_apr_MD5Final = (const void *)apr_MD5Final;
> const void *ap_hack_apr_MD5Init = (const void *)apr_MD5Init;
>
> Alternatively, we can declare all possible functions in the apr header
> files regardless of the configuration.
>
> Any preferences?
I like not needing the declarations regardless of the config. In other
words exports.c should declare the functions.
This should be VERY easy to add to the script that generates the
code. Question though. Won't AIX get messed up if there are functions in
httpd.exp that aren't defined?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------