Re: [PATCH (1.3)] Export functions defined in httpd.exp

[William A. Rowe, Jr.]

From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 9:29 AM


> I am still thinking this one over... I really don't like the idea of breaking binary
> backward compatability but concede we should not let that prevent us from new 
>development.
> 
> If we go with this, I would like a CVS tag before the work starts.

Not a release tag, I presume.  Plus a post-declare tag as well, no?

The more I think about it, the more possible it is that this may not
break things in the way I expected, stay tuned [2.0 builds clean, on
to checking 1.3.]  Of course, we retain the .def file in the 1.3 tree
or binary compatibility will be entirely horked.

Bill

Re: [PATCH (1.3)] Export functions defined in httpd.exp

[William A. Rowe, Jr.]

From: "Thomas Eibner" <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 9:24 AM


> On Fri, Dec 21, 2001 at 09:08:27AM -0600, William A. Rowe, Jr. wrote:
> > 
> > Ok.  Here's my take.  Your patch breaks mod_ssl EAPI's patch (makes some
> > of it superfluous, actually) and breaks ALL binary compatibility.
> > 
> > Lets go for it :)
> 
> But it's better to get it over with in one take right?

You could put it that way, yes.  There is the question of breaking the .def
file entirely, but I doubt we want to go that direction.

> > Here's my suggestion.  Do as you've advocated [based on httpd.exp].  But
> > DROP the ordinals on Win32.  The hash-lookup of the fn names that occurs
> > under the covers makes the differences nill.  Modules will continue to be 
> > backwards compatible from, oh, maybe version 1.3.14 or whenever we last 
> > horked with the structs.  But no older modules will be forward compatible, 
> > since they were bound by ordinal value.
> 
> So what do you want me to do with the Win32 part?

Nothing, right now.  I have some serious problems with EXPORT v.s. EXPORT_NONSTD,
and not all of them (perhaps not any of them) are issues with _your_ patch.
This stuff may have been that way for sometime.  And the distinction may noop, 
but they need to be corrected for clarity.

> > I'll experiment and consider applying your patch.  Without a veto, and 
> > after Brad has reviewed this on Netware, I would be happy to commit the
> > patch, with the appropriate no-ordinals fix [probably as a seperate step.]
> 
> And we definitelly want to make sure I exported all the functions
> correctly before applying it. I had a fair part of the actual patching
> automated with and kept an eye on what it did. I would just like for
> someone other than myself to verify that I'm using the correct 
> API_EXPORT,CORE_EXPORT,API_EXPORT_NONSTD definitions all over. 

That's why I toggle the .def file - by pulling it, and listing symbols, I can
quickly determine which are/are not correctly exported :)  As I say, your patch
is in-motion, and will change a bit perhaps before the final 'assult' on the
sources (with before-1_3_23-exports, after- cvs tags).

Bill

Re: [PATCH (1.3)] Export functions defined in httpd.exp

[William A. Rowe, Jr.]

From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 9:08 AM


> From: "Thomas Eibner" <[EMAIL PROTECTED]>
> Sent: Friday, December 21, 2001 8:26 AM
> 
> 
> > A few months ago I proposed a patch (With Gunter Knauf's help) that
> > would make my module mod_rpaf compile on Win32 and netware. It used
> > the ap_update_vhost_from_headers function which wasn't correctly
> > exported for it to compile. I proposed a patch to make that work,
> > but was told that it would be nice to get the rest of the functions
> > from httpd.exp exported too.
> 
> Here's my suggestion.  Do as you've advocated [based on httpd.exp].  But
> DROP the ordinals on Win32.  The hash-lookup of the fn names that occurs
> under the covers makes the differences nill.  Modules will continue to be 
> backwards compatible from, oh, maybe version 1.3.14 or whenever we last 
> horked with the structs.  But no older modules will be forward compatible, 
> since they were bound by ordinal value.

The other alternative, not as clean, is to drop the .def file altogether
for win32, since the EXPORT macros make it unnecessary.  HOWEVER, this
entirely breaks Win32 binary compatibility, since the names will be quite
decorated (leading underbars, trailing @args.)

I'm not terribly in favor of the alternative for 1.3.  Anyone have other
thoughts?

Re: [PATCH (1.3)] Export functions defined in httpd.exp

[Bill Stoddard]

I am still thinking this one over... I really don't like the idea of breaking binary
backward compatability but concede we should not let that prevent us from new 
development.

If we go with this, I would like a CVS tag before the work starts.

Bill

> From: "Thomas Eibner" <[EMAIL PROTECTED]>
> Sent: Friday, December 21, 2001 8:26 AM
>
>
> > A few months ago I proposed a patch (With Gunter Knauf's help) that
> > would make my module mod_rpaf compile on Win32 and netware. It used
> > the ap_update_vhost_from_headers function which wasn't correctly
> > exported for it to compile. I proposed a patch to make that work,
> > but was told that it would be nice to get the rest of the functions
> > from httpd.exp exported too.
>
> Hmmm.
>
> Ok.  Here's my take.  Your patch breaks mod_ssl EAPI's patch (makes some
> of it superfluous, actually) and breaks ALL binary compatibility.
>
> Lets go for it :)
>
> Here's my suggestion.  Do as you've advocated [based on httpd.exp].  But
> DROP the ordinals on Win32.  The hash-lookup of the fn names that occurs
> under the covers makes the differences nill.  Modules will continue to be
> backwards compatible from, oh, maybe version 1.3.14 or whenever we last
> horked with the structs.  But no older modules will be forward compatible,
> since they were bound by ordinal value.
>
> I'll experiment and consider applying your patch.  Without a veto, and
> after Brad has reviewed this on Netware, I would be happy to commit the
> patch, with the appropriate no-ordinals fix [probably as a seperate step.]
>
> Bill
>
>
>
>
>

Re: [PATCH (1.3)] Export functions defined in httpd.exp

[Thomas Eibner]

On Fri, Dec 21, 2001 at 09:08:27AM -0600, William A. Rowe, Jr. wrote:
> Hmmm.
> 
> Ok.  Here's my take.  Your patch breaks mod_ssl EAPI's patch (makes some
> of it superfluous, actually) and breaks ALL binary compatibility.
> 
> Lets go for it :)

But it's better to get it over with in one take right?

> Here's my suggestion.  Do as you've advocated [based on httpd.exp].  But
> DROP the ordinals on Win32.  The hash-lookup of the fn names that occurs
> under the covers makes the differences nill.  Modules will continue to be 
> backwards compatible from, oh, maybe version 1.3.14 or whenever we last 
> horked with the structs.  But no older modules will be forward compatible, 
> since they were bound by ordinal value.

So what do you want me to do with the Win32 part?

> I'll experiment and consider applying your patch.  Without a veto, and 
> after Brad has reviewed this on Netware, I would be happy to commit the
> patch, with the appropriate no-ordinals fix [probably as a seperate step.]

And we definitelly want to make sure I exported all the functions
correctly before applying it. I had a fair part of the actual patching
automated with and kept an eye on what it did. I would just like for
someone other than myself to verify that I'm using the correct 
API_EXPORT,CORE_EXPORT,API_EXPORT_NONSTD definitions all over. 

thanks,

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Re: [PATCH (1.3)] Export functions defined in httpd.exp

[William A. Rowe, Jr.]

From: "Thomas Eibner" <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 8:26 AM


> A few months ago I proposed a patch (With Gunter Knauf's help) that
> would make my module mod_rpaf compile on Win32 and netware. It used
> the ap_update_vhost_from_headers function which wasn't correctly
> exported for it to compile. I proposed a patch to make that work,
> but was told that it would be nice to get the rest of the functions
> from httpd.exp exported too.

Hmmm.

Ok.  Here's my take.  Your patch breaks mod_ssl EAPI's patch (makes some
of it superfluous, actually) and breaks ALL binary compatibility.

Lets go for it :)

Here's my suggestion.  Do as you've advocated [based on httpd.exp].  But
DROP the ordinals on Win32.  The hash-lookup of the fn names that occurs
under the covers makes the differences nill.  Modules will continue to be 
backwards compatible from, oh, maybe version 1.3.14 or whenever we last 
horked with the structs.  But no older modules will be forward compatible, 
since they were bound by ordinal value.

I'll experiment and consider applying your patch.  Without a veto, and 
after Brad has reviewed this on Netware, I would be happy to commit the
patch, with the appropriate no-ordinals fix [probably as a seperate step.]

Bill

[PATCH (1.3)] Export functions defined in httpd.exp

[Thomas Eibner]

Hi,

A few months ago I proposed a patch (With Gunter Knauf's help) that
would make my module mod_rpaf compile on Win32 and netware. It used
the ap_update_vhost_from_headers function which wasn't correctly
exported for it to compile. I proposed a patch to make that work,
but was told that it would be nice to get the rest of the functions
from httpd.exp exported to. So here is my first take at it (finally):

Notes:
I've deliberatly left out the XML_ space.
Some functions were a bit tricky:
ap_dummy_mutex
ap_listeners
ap_os_is_path_absolute
ap_prelinked_modules
ap_preloaded_modules
ap_rfc1413_timeout
ap_scoreboard_image
ap_signal
ap_slack
ap_sys_siglist
ap_util_init
ap_util_uri_init

The rest of the functions should be exported now. Anyone care to take
a look if they're all done right? 

Are there any more platforms it need to be done for?

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  



Index: src/ApacheCore.def
===
RCS file: /home/cvspublic/apache-1.3/src/ApacheCore.def,v
retrieving revision 1.28
diff -u -r1.28 ApacheCore.def
--- src/ApacheCore.def  2000/12/27 21:45:11 1.28
+++ src/ApacheCore.def  2001/12/21 14:04:03
@@ -389,3 +389,54 @@
ap_stripprefix @380
 ap_os_dso_load @381
 ap_os_dso_error @382
+ap_update_vhost_from_headers @383
+ap_update_vhost_given_ip @384
+ap_set_name_virtual_host @385
+ap_parse_vhost_addrs @386
+ap_fini_vhost_config @387
+ap_init_vhost_config @388
+ap_check_access @389
+ap_check_auth @390
+ap_check_user_id @391
+ap_translate_name @392
+ap_find_types @393
+ap_run_fixups @394
+ap_invoke_handler @395
+ap_log_transaction @396
+ap_header_parse @397
+ap_run_post_read_request @398
+ap_single_module_configure @399
+ap_init_modules @400
+ap_child_init_modules @401
+ap_child_exit_modules @402
+ap_setup_prelinked_modules @403
+ap_show_directives @404
+ap_show_modules @405
+ap_parse_htaccess @406
+ap_process_resource_config @407
+ap_create_request_config @408
+ap_merge_per_dir_configs @409
+ap_bind_address @410
+ap_core_reorder_directories @411
+ap_coredump_dir @412
+ap_force_library_loading @413
+ap_get_local_host @414
+ap_get_virthost_addr @415
+ap_init_alloc @416
+ap_keepalive_timeout @417
+ap_listenbacklog @418
+ap_lock_fname @419
+ap_log_pid @420
+ap_open_logs @421
+ap_process_request @422
+ap_read_config @423
+ap_read_request @423
+ap_response_code_string @424
+ap_rfc1413 @425
+ap_send_http_options @426
+ap_server_config_defines @427
+ap_server_post_read_config @428
+ap_server_pre_read_config @429
+ap_set_callback_and_alarm @430
+ap_set_sub_req_protocol @431
+ap_update_child_status @432


Index: src/os/netware/ApacheCore.imp
===
RCS file: /home/cvspublic/apache-1.3/src/os/netware/ApacheCore.imp,v
retrieving revision 1.9
diff -u -r1.9 ApacheCore.imp
--- src/os/netware/ApacheCore.imp   2001/08/13 21:40:45 1.9
+++ src/os/netware/ApacheCore.imp   2001/12/21 14:12:37
@@ -362,4 +362,55 @@
  ap_os_canonical_filename,
  ap_os_http_method,
  os_readdir,
- os_opendir
+ os_opendir,
+ ap_update_vhost_from_headers,
+ ap_update_vhost_given_ip,
+ ap_set_name_virtual_host,
+ ap_parse_vhost_addrs,
+ ap_fini_vhost_config,
+ ap_init_vhost_config, 
+ ap_check_access,
+ ap_check_auth,
+ ap_check_user_id,
+ ap_translate_name,
+ ap_find_types,
+ ap_run_fixups,
+ ap_invoke_handler,
+ ap_log_transaction,
+ ap_header_parse,
+ ap_run_post_read_request,
+ ap_single_module_configure,
+ ap_init_modules,
+ ap_child_init_modules,
+ ap_child_exit_modules,
+ ap_setup_prelinked_modules,
+ ap_show_directives,
+ ap_show_modules,
+ ap_parse_htaccess,
+ ap_process_resource_config,
+ ap_create_request_config,
+ ap_merge_per_dir_configs,
+ ap_bind_address,
+ ap_core_reorder_directories,
+ ap_coredump_dir,
+ ap_force_library_loading,
+ ap_get_local_host,
+ ap_get_virthost_addr,
+ ap_init_alloc,
+ ap_keepalive_timeout,
+ ap_listenbacklog,
+ ap_lock_fname,
+ ap_log_pid,
+ ap_open_logs,
+ ap_process_request,
+ ap_read_config,
+ ap_read_request,
+ ap_response_code_string,
+ ap_rfc1413,
+ ap_send_http_options,
+ ap_server_config_defines,
+ ap_server_post_read_config,
+ ap_server_pre_read_config,
+ ap_set_callback_and_alarm,
+ ap_set_sub_req_protocol,
+ ap_update_child_status,


Index: src/main/alloc.c
===
RCS file: /home/cvspublic/apache-1.3/src/main/alloc.c,v
retrieving revision 1.123
diff -u -r1.123 alloc.c
--- src/main/all