Enrico Weigelt wrote:
snip
Dependencies are to be tracked by a vendor, not by our users who
download the source from us.
Ah, great. And when will be the day when glibc is included in httpd ?
Never. glibc is GPL/LGPLed, and the httpd server project cannot
distribute it as part of our license and
* Paul Querna [EMAIL PROTECTED] wrote:
Enrico Weigelt wrote:
snip
Dependencies are to be tracked by a vendor, not by our users who
download the source from us.
Ah, great. And when will be the day when glibc is included in httpd ?
Never. glibc is GPL/LGPLed, and the httpd server project
On Mon, Dec 13, 2004 at 12:57:36AM -0700, Paul Querna wrote:
I agree with you however, but this is the current state of httpd.
Patches to allow using of external libs for everything we currently
embed are extremely welcome.
For external PCRE:
* Paul Querna [EMAIL PROTECTED] wrote:
snip
srclib/apr-util/configure --help | grep expat
--with-expat=DIRspecify Expat location
Ah, yeah. I've grepped for --with-pcre, which is missing.
I'm now trying it on my buildfarm ...
snip
btw: why is it a goal to put all dependencies into
* Joe Orton [EMAIL PROTECTED] wrote:
snip
Is there any reason to keep libpcre in the httpd tree?
untar configure make must just work on any random Unix system.
shot yourself.
apache2 requires expat, which is less common than pcre.
snip
Those are bugs which can be fixed by optionally
Enrico Weigelt wrote:
* Joe Orton [EMAIL PROTECTED] wrote:
snip
Is there any reason to keep libpcre in the httpd tree?
untar configure make must just work on any random Unix system.
shot yourself.
apache2 requires expat, which is less common than pcre.
does not. APR-Util embeds expat.
-Paul
Enrico Weigelt wrote:
* Paul Querna [EMAIL PROTECTED] wrote:
snip
shot yourself.
apache2 requires expat, which is less common than pcre.
does not. APR-Util embeds expat.
eh? uglier than i thouht!
why isnt there an --with-expat=... option for enforcing use of
external expat ?
There is:
* Paul Querna [EMAIL PROTECTED] wrote:
snip
shot yourself.
apache2 requires expat, which is less common than pcre.
does not. APR-Util embeds expat.
eh? uglier than i thouht!
why isnt there an --with-expat=... option for enforcing use of
external expat ?
embedding standard libraries
Brian Pane wrote:
Richard Jones wrote:
On Thu, Nov 25, 2004 at 04:00:46PM -0800, Brian Pane wrote:
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few
days.
Any chance of integrating the fix in bug 27550 at
--On Sunday, November 28, 2004 3:36 PM -0800 Brian Pane [EMAIL PROTECTED]
wrote:
Meanwhile, now that we have the latest release of PCRE in httpd-2.1, one
option would help somewhat would be to backport it into httpd-2.0.
I doubt we'd be able to maintain binary compatibility if we did that. So,
Justin Erenkrantz wrote:
--On Sunday, November 28, 2004 3:36 PM -0800 Brian Pane
[EMAIL PROTECTED] wrote:
Meanwhile, now that we have the latest release of PCRE in httpd-2.1, one
option would help somewhat would be to backport it into httpd-2.0.
I doubt we'd be able to maintain binary
* Brian Pane wrote:
Okay, I checked out the patch attached to that bug. Supporting the use
of an external copy of PCRE makes sense.
+1 on concept.
The patch also changes various
core PCRE function names to ap_*. That definitely helps prevent
collisions with libc or libpthread versions
On Sun, Nov 28, 2004 at 03:39:33PM -0800, Justin Erenkrantz wrote:
--On Sunday, November 28, 2004 3:36 PM -0800 Brian Pane [EMAIL PROTECTED]
wrote:
Meanwhile, now that we have the latest release of PCRE in httpd-2.1, one
option would help somewhat would be to backport it into httpd-2.0.
* Richard Jones wrote:
Is this (binary compatibility) really a policy?
Yes.
nd
--
Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)
-- aus einer Rezension
http://pub.perlig.de/books.html#apache2
On Fri, Nov 26, 2004 at 11:55:35PM -0800, Brian Pane wrote:
Yep. I just did that, and it worked as expected. I ended up with a
clean merge: the only files that needed merge conflict resolution were
those that had been modified in the srclib/pcre copy:
Looks good, thanks Brian. Do you
Joe Orton wrote:
On Fri, Nov 26, 2004 at 11:55:35PM -0800, Brian Pane wrote:
Yep. I just did that, and it worked as expected. I ended up with a
clean merge: the only files that needed merge conflict resolution were
those that had been modified in the srclib/pcre copy:
Looks good,
On Thu, Nov 25, 2004 at 04:00:46PM -0800, Brian Pane wrote:
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few days.
Any chance of integrating the fix in bug 27550 at the same time?
While trying to get NetWare to build with the new PCRE update, I
noticed that there is a duplicate of pcreposix.h in both include/ and
srclib/pcre/ directories. Currently they don't match which is causing
the NetWare build to break. I can sync them up, but the real question
is should this
Brad Nicholes wrote:
While trying to get NetWare to build with the new PCRE update, I
noticed that there is a duplicate of pcreposix.h in both include/ and
srclib/pcre/ directories. Currently they don't match which is causing
the NetWare build to break. I can sync them up, but the real
Richard Jones wrote:
On Thu, Nov 25, 2004 at 04:00:46PM -0800, Brian Pane wrote:
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few days.
Any chance of integrating the fix in bug 27550 at the same time?
On Thu, Nov 25, 2004 at 04:00:46PM -0800, Brian Pane wrote:
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few days.
One question, though...
I'd like to follow the vendor-branch approach outlined in the
Joe Orton wrote:
I also spent some time recently working out how to apply that process to
srclib/pcre and it seemed fairly straight-forward. It seems like the
process works OK even if the step to copy the original vendor
pcre/current to srclib/pcre is skipped, so the current srclib/pcre can
be
I volunteer to upgrade the copy of PCRE in httpd-2.1 to the latest
version. I'll have a bit of time to work on this over the next few days.
One question, though...
I'd like to follow the vendor-branch approach outlined in the Subversion
book, http://svnbook.red-bean.com/en/1.0/ch07s04.html.
On Wed, Nov 17, 2004 at 05:01:48PM -0800, Brian Pane wrote:
About two years ago, I made some performance optimizations to the copy
of pcre in the httpd-2.0 tree. I submitted the diffs to the pcre
maintainer, but I don't know if they've made it into a subsequent pcre
release.
Yep, these have
Is there any reason to keep libpcre in the httpd tree?
I believe we should use the PCRE installed on the system. If its not on
the system, the user can install it. There are several bugs from 3rd
party modules that also try to use pcre, and get conflicting symbols
because of the version
On Wed, Nov 17, 2004 at 10:34:41AM -0800, Paul Querna wrote:
Is there any reason to keep libpcre in the httpd tree?
untar configure make must just work on any random Unix system.
I believe we should use the PCRE installed on the system. If its not on
the system, the user can install it.
Paul Querna wrote:
Is there any reason to keep libpcre in the httpd tree?
I believe we should use the PCRE installed on the system. If its not on
the system, the user can install it. There are several bugs from 3rd
party modules that also try to use pcre, and get conflicting symbols
because
* Joe Orton [EMAIL PROTECTED] wrote:
On Wed, Nov 17, 2004 at 10:34:41AM -0800, Paul Querna wrote:
Is there any reason to keep libpcre in the httpd tree?
untar configure make must just work on any random Unix system.
I believe we should use the PCRE installed on the system. If its not
On Wed, Nov 17, 2004 at 09:05:38PM +0100, Andr Malo wrote:
But we should take the effort and try to keep up to date. Current PCRE version
is 5.0 with many many bugfixes and optimizations since 3.9, which we're using.
I've tried to update the stuff from time to time, but my autofoo knowledge
Paul Querna wrote:
Is there any reason to keep libpcre in the httpd tree?
I believe we should use the PCRE installed on the system. If its not
on the system, the user can install it. There are several bugs from
3rd party modules that also try to use pcre, and get conflicting
symbols because
30 matches
Mail list logo
