httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Prior to apr 2.0 / httpd 2.4...
Date Mon, 21 Mar 2011 23:05:10 GMT
On Mon, Mar 21, 2011 at 12:23, Guenter Knauf <fuankg@apache.org> wrote:
> Greg,
> Am 21.03.2011 15:38, schrieb Greg Stein:
>...
>> I'm a committer on Expat, but (as you've noted) the project has had no
>> attention for quite a while. I wasn't aware of a security problem in
>> there, however.
>>
>> Even if I dropped a new release of Expat, would we want to rely on the
>> external build (and latest release being propagated) or continue to
>> ship a patched Expat within APR?
>>
>> Switching to libxml2 would be possible (it is MIT licensed), but would
>> require a lot more coding work in the xml support. Users of APR (1.x)
>> also depend on Expat being available, and a switch would require them
>> to rewrite their XML parsing code. Maybe that is acceptable for apps
>> to switch to 2.0?
>
> I followed up with libxml2 for a while on NetWare, and every now and then
> compilation was broken with next release due to not only fixing bugs but
> also adding a bunch of new features which then require futher tweaks (search
> for stubs which provide missing OS functions in network layer, etc).
> Further more many projects dont care about issues with compilers which dont
> like declarations after statements, and often you then end up with
> uncompilable code :-(

Yeah. In Subversion, we have a bunch of Windows developers, and they
call out when declarations occur after statements :-)

>> In short: I can make a release happen, but would that matter to the APR
>> project?
>
> when I tried to compile for Win32 with Watcom C I had to add this to expat:
> --- expat.h.orig        Mon Nov 27 03:51:58 2006
> +++ expat.h     Mon Aug 09 16:27:36 2010
> @@ -193,11 +193,19 @@
>                       XML_XmlDeclHandler xmldecl);
>
>
> +#if defined(WIN32) && defined(__WATCOMC__)
> +typedef struct {
> +  void * __watcall (*malloc_fcn)(size_t size);
> +  void * __watcall (*realloc_fcn)(void *ptr, size_t size);
> +  void __watcall (*free_fcn)(void *ptr);
> +} XML_Memory_Handling_Suite;
> +#else
>  typedef struct {
>   void *(*malloc_fcn)(size_t size);
>   void *(*realloc_fcn)(void *ptr, size_t size);
>   void (*free_fcn)(void *ptr);
>  } XML_Memory_Handling_Suite;
> +#endif

Seems reasonable. There have been a number of other little compilation
bug reports that have crept in over time. Could probably spend a day
just closing out those issues.

>  /* Constructs a new parser; encoding is the encoding specified by the
>    external protocol or NULL if there is none specified.
>
> BTW. is there a public repo from where oen can fetch current code?

http://sourceforge.net/scm/?type=cvs&group_id=10127

> oh, and while on things to fix where you are commiter:
> another one who plays with httpd and subversion on NetWare told me that
> current code of libserf has its quirks on NetWare - are you willing to take
> a look into that before we go for httpd GA?

I don't see how httpd GA is related to serf?? ... certainly, you want
serf fixed up for a NetWare Subversion. But does httpd 2.4 consume
libserf nowadays? (ie. one of the proxy modules?)

> And where to post patches? To you directly?

serf-dev@googlegroups.com

and/or open issues at code.google.com/p/serf/

Cheers,
-g

Mime
View raw message