You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2005/03/02 03:36:40 UTC

[multi-env] APR__Request__Param.h question

In building and testing the perl glue on Win32, I've run
into a problem with apreq_env_temp_dir() not being found
in libapreq2.dll - this is referenced in
 glue/perl/xsbuilder/APR/Request/Param/APR__Request__Param.h
I'm afraid I couldn't follow where this function should
be coming from? Thanks.

-- 
best regards,
randy

Re: [multi-env] APR__Request__Param.h question

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:

[...]

> I'd agree with that - you've done some amazing things with
> ExtUtils::XSBuilder, but as things grow, it looks like
> vanilla XS would be easier.

Thanks.  XSBuilder is just a bad fit for a project
like this, where lots of context-specific glue needs
to be written.

> In the meantime, would something like the following
> (untested)
>    #ifdef WIN32
>    #define index strchr
>    #endif
> in glue/perl/xsbuilder/APR/Request/Param/Param.xs
> be OK?

index() isn't portable, so it was a bad workaround in the 
first place.  My other suggestion, to parenthesize (strchr)
and add a comment, doesn't work on Win32?

Either way, these solutions are just temporary fixes
until we can do away with ExtUtils::XBuilder, so 
anything you choose to commit will be fine with me.

-- 
Joe Schaefer

Re: [multi-env] APR__Request__Param.h question

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 2 Mar 2005, Joe Schaefer wrote:

[ ... ]
> I'm not sure where the blame lies here, but I've grown very
> tired of fixing problems that involve ExtUtils::XSBuilder.
> I think it's time to consider replacing that with vanilla
> XS.  It's both more powerful and IMO much easier to maintain.

I'd agree with that - you've done some amazing things with
ExtUtils::XSBuilder, but as things grow, it looks like
vanilla XS would be easier.

In the meantime, would something like the following
(untested)
   #ifdef WIN32
   #define index strchr
   #endif
in glue/perl/xsbuilder/APR/Request/Param/Param.xs
be OK?

-- 
best regards,
randy

Re: [multi-env] APR__Request__Param.h question

Posted by Joe Schaefer <jo...@sunstarsys.com>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:

> Next obvious question - where did AP_DEBUG get triggered?

I think the logic chain runs like this

  1) I configured httpd with --enable-maintainer-mode, which sets -DAP_DEBUG,

  2) mp2 picks up that flag from the httpd installation via Apache::Build's 
     invocation of `apxs -q EXTRA_CPPFLAGS`,

  3) Our ExtUtils::XSBuilder stuff uses ModPerl::MM::WriteMakefile 
     in its generated Makefile.PLs.  Also EU::XSBuilder is
     indiscrimimate about header files, so the generated *.xs 
     files will list every header file it finds in our tree.
     So even though the generated Param.xs is an apr-only app,
     httpd.h winds up being included in there, through the 
     (needless) apreq_module_apache2.h include.

  3) ModPerl::MM::WriteMakefile adds that `apxs -q EXTRA_CPPFLAGS` stuff 
     from Apache::Build to the CCFLAGS variable in the resulting Makefiles.


I'm not sure where the blame lies here, but I've grown very 
tired of fixing problems that involve ExtUtils::XSBuilder.
I think it's time to consider replacing that with vanilla
XS.  It's both more powerful and IMO much easier to maintain.

-- 
Joe Schaefer

Re: [multi-env] APR__Request__Param.h question

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Next obvious question - where did AP_DEBUG get triggered?

At 12:03 PM 3/2/2005, Joe Schaefer wrote:
>"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
>> At 06:24 AM 3/2/2005, Joe Schaefer wrote:
>>
>>>Argh. For some reason the current set of build headers overrides 
>>>strchr with ap_strchr, which takes non-const args.
>
>Probably httpd.h with AP_DEBUG declared:
>
>#ifdef AP_DEBUG
>
>#undef strchr
># define strchr(s, c)   ap_strchr(s,c)
>#undef strrchr
># define strrchr(s, c)  ap_strrchr(s,c)
>#undef strstr
># define strstr(s, c)  ap_strstr(s,c)
>
>#else
>
>
>-- 
>Joe Schaefer

Re: [multi-env] APR__Request__Param.h question

Posted by Joe Schaefer <jo...@sunstarsys.com>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:

> At 06:24 AM 3/2/2005, Joe Schaefer wrote:
>
>>Argh. For some reason the current set of build headers overrides 
>>strchr with ap_strchr, which takes non-const args.

Probably httpd.h with AP_DEBUG declared:

#ifdef AP_DEBUG

#undef strchr
# define strchr(s, c)	ap_strchr(s,c)
#undef strrchr
# define strrchr(s, c)  ap_strrchr(s,c)
#undef strstr
# define strstr(s, c)  ap_strstr(s,c)

#else


-- 
Joe Schaefer

Re: [multi-env] APR__Request__Param.h question

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:24 AM 3/2/2005, Joe Schaefer wrote:

>Argh. For some reason the current set of build headers overrides 
>strchr with ap_strchr, which takes non-const args.

Where?  Pointer to this redefinition please?

>       /* Parens around strchr to prevent bogus ap_strchr override */
>       if ((sc = (strchr)(ct, ';')))

This is just wrong.  strchr has one declaration, ap_strchr
was created for the alternate purpose.

Bill

Re: [multi-env] APR__Request__Param.h question

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:

[...]

> As well, with VC++ index(), used in
>    glue/perl/xsbuilder/APR/Request/Param/Param.xs
> isn't available. Is strchr() equivalent?

Argh. For some reason the current set of build headers overrides 
strchr with ap_strchr, which takes non-const args.  That's why 
I chose index() instead of strchr() here, but index is a BSDism.

[...]

> -    if ((sc = index(ct, ';')))
> +    if ((sc = strchr(ct, ';')))

Writing it this way should avoid the ap_strchr override:

       /* Parens around strchr to prevent bogus ap_strchr override */
       if ((sc = (strchr)(ct, ';')))

If that works on Windows also, please commit.

-- 
Joe Schaefer

Re: [multi-env] APR__Request__Param.h question

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:

> As a workaround, I used this patch:

+1.

-- 
Joe Schaefer

Re: [multi-env] APR__Request__Param.h question

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 1 Mar 2005, Joe Schaefer wrote:

> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> [...]
>
> > No problem - thanks. That is very strange that it would
> > be causing problems - I didn't notice the #if 0 #endif
> > surrounding it, but it is there. This is probably due
> > to some anomalies I'm seeing with ExtUtils::XSBuilder;
> > I'll look into this.
>
> Right, I just ported everything there except for the
> Apache::Upload::Brigade wrappers, and I will remove
> that garbage now to avoid any remaining Win32 problems.
> No need waste your time debugging something like this.

It turned out to be a strange (Win32) problem ...
Apache::Request wasn't installed into
blib/lib/Apache2/Apache/Request.pm (it went into
blib/lib/Apache/Request.pm), and so when running the tests,
it picked up an older Apache::Request from my system Perl,
which needed the symbol that the new libapreq2.dll doesn't
have. I'm not sure where the problem lies: this Makefile.PL

use Apache2;
use ModPerl::MM;
ModPerl::MM::WriteMakefile(
  NAME => 'foo',
);

with a lib/Apache/Bar.pm at the same level will install
it into blib/lib/Apache/Bar.pm (ie, without an Apache2
subdirectory, as happens on Unix). So it's something
either on the ModPerl::MM side, or perhaps ExtUtils::*.

As a workaround, I used this patch:
==========================================================
Index: glue/perl/Makefile.PL
===================================================================
--- glue/perl/Makefile.PL	(revision 155885)
+++ glue/perl/Makefile.PL	(working copy)
@@ -139,6 +139,7 @@
 package My::WrapXS;
 use base qw/ExtUtils::XSBuilder::WrapXS/;
 our $VERSION = $version;
+use constant WIN32 => ($^O =~ /Win32/i);

 ##################################################
 # Finally, we get to the actual script...
@@ -159,13 +160,24 @@
 Apache::TestSmokePerl->generate_script;
 Apache::TestReportPerl->generate_script;

-ModPerl::MM::WriteMakefile(
+my %opts = (
     NAME => 'libapreq2',
     DIR => [qw(xs)],
     clean => { FILES => "xs t/logs t/TEST @scripts" },
     realclean => { FILES => "xsbuilder/tables" },
 );

+if (WIN32) {
+    my $PM = {
+        'lib/Apache/Request.pm' => '$(INST_LIB)/Apache/Request.pm',
+        'lib/Apache/Upload.pm' => '$(INST_LIB)/Apache/Upload.pm',
+        'lib/Apache/Cookie.pm' => '$(INST_LIB)/Apache/Cookie.pm',
+    };
+    $opts{PM} = $PM;
+}
+
+ModPerl::MM::WriteMakefile(%opts);
+
 # That's the whole script - below is just a bunch of local overrides
 ##################################################
 sub get_functions {
=====================================================================

Does this look OK?

As well, with VC++ index(), used in
   glue/perl/xsbuilder/APR/Request/Param/Param.xs
isn't available. Is strchr() equivalent?

================================================================
Index: glue/perl/xsbuilder/APR/Request/Param/Param.xs
===================================================================
--- glue/perl/xsbuilder/APR/Request/Param/Param.xs	(revision 155885)
+++ glue/perl/xsbuilder/APR/Request/Param/Param.xs	(working copy)
@@ -585,7 +585,7 @@
     if (ct == NULL)
         Perl_croak(aTHX_ "$param->upload_type: can't find Content-Type header");

-    if ((sc = index(ct, ';')))
+    if ((sc = strchr(ct, ';')))
         len = sc - ct;
     else
         len = strlen(ct);

Property changes on: glue/perl/xsbuilder/APR/Request/Param/Param.xs
___________________________________________________________________
Name: svn:eol-style
   + native

=====================================================================

With the above 2 changes, the perl glue all builds, and the
tests pass, save for the expected failures at this point
in time.

-- 
best regards,
randy

Re: [multi-env] APR__Request__Param.h question

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:


[...]

> No problem - thanks. That is very strange that it would
> be causing problems - I didn't notice the #if 0 #endif
> surrounding it, but it is there. This is probably due
> to some anomalies I'm seeing with ExtUtils::XSBuilder;
> I'll look into this.

Right, I just ported everything there except for the 
Apache::Upload::Brigade wrappers, and I will remove
that garbage now to avoid any remaining Win32 problems. 
No need waste your time debugging something like this.

-- 
Joe Schaefer

Re: [multi-env] APR__Request__Param.h question

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 1 Mar 2005, Joe Schaefer wrote:

> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
> > In building and testing the perl glue on Win32, I've run
> > into a problem with apreq_env_temp_dir() not being found
> > in libapreq2.dll - this is referenced in
> >  glue/perl/xsbuilder/APR/Request/Param/APR__Request__Param.h
> > I'm afraid I couldn't follow where this function should
> > be coming from? Thanks.
>
> Terribly sorry about that.  I'm working on the
> remaining Apache::Upload API now, and I just dumped
> a copy of the old unported XS (from Apache__Upload.h)
> into that file.
>
> OTOH, the whole section of dumped code is
> commented out within an #if 0 #endif block.  I
> wonder why it's causing Win32 grief?

No problem - thanks. That is very strange that it would
be causing problems - I didn't notice the #if 0 #endif
surrounding it, but it is there. This is probably due
to some anomalies I'm seeing with ExtUtils::XSBuilder;
I'll look into this.

-- 
best regards,
randy

Re: [multi-env] APR__Request__Param.h question

Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:

> In building and testing the perl glue on Win32, I've run
> into a problem with apreq_env_temp_dir() not being found
> in libapreq2.dll - this is referenced in
>  glue/perl/xsbuilder/APR/Request/Param/APR__Request__Param.h
> I'm afraid I couldn't follow where this function should
> be coming from? Thanks.

Terribly sorry about that.  I'm working on the 
remaining Apache::Upload API now, and I just dumped
a copy of the old unported XS (from Apache__Upload.h)
into that file.

OTOH, the whole section of dumped code is
commented out within an #if 0 #endif block.  I 
wonder why it's causing Win32 grief?

-- 
Joe Schaefer