Uhmmm... that's exactly what we are trying to avoid.
E.g. always provide the symbols to link. Lets say you've build mod_foo,
and built it against a debugging build of httpd. Now you go to put it into
production (you forget to recompile.)
Should you be kicked in the rear for trying? Or should those symbols
still exist ... we are leaning twords consistently providing the exported
function stubs. Now if you compile in a release mode you won't end up
with any linkage to those stubs, they are all macros. But this provides
that the module built for debugging will drop right into a production build.
Bill
At 11:43 AM 3/11/2003, [EMAIL PROTECTED] wrote:
>bnicholes 2003/03/11 09:43:37
>
> Modified: build Tag: APACHE_2_0_BRANCH make_nw_export.awk
> Log:
> Specify a set of APIs that are normally defined as macros and should not be
> included in the export list.
>
> Revision Changes Path
> No revision
>
>
> No revision
>
>
> 1.10.2.1 +13 -0 httpd-2.0/build/make_nw_export.awk
>
> Index: make_nw_export.awk
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/build/make_nw_export.awk,v
> retrieving revision 1.10
> retrieving revision 1.10.2.1
> diff -u -r1.10 -r1.10.2.1
> --- make_nw_export.awk 19 Jul 2002 19:48:49 -0000 1.10
> +++ make_nw_export.awk 11 Mar 2003 17:43:36 -0000 1.10.2.1
> @@ -8,6 +8,19 @@
> # List of functions that we don't support, yet??
> #/ap_some_name/{next}
>
> +# The following APIs are actually defined as macros and
> +# should not be included in the export list. If util_debug.c
> +# is included or AP_DEBUG is defined, these macros turn
> +# into functions and should be included in the export list.
> +/ap_get_module_config/{next}
> +/ap_set_module_config/{next}
> +/ap_strchr/{next}
> +/ap_strchr_c/{next}
> +/ap_strrchr/{next}
> +/ap_strrchr_c/{next}
> +/ap_strstr/{next}
> +/ap_strstr_c/{next}
> +
>
> function add_symbol (sym_name) {
> if (count) {
>
>
>
