Huh? sdbm.h is exported by APRUTIL. It is a publically available
export. Or,
it should be at least.
Then the header name at the very least needs to change. As it is now,
if
we install Apache on a machine that already has sdbm, we will break
things
On Fri, Dec 08, 2000 at 04:20:17PM -0800, [EMAIL PROTECTED] wrote:
One last observation, sdbm.h does _not_ belong in apr-util/include/ and
neither
does the apu_private stuff. Suggest we move those on out of there, but
where?
apr-util/include/private? We don't need arch/
On Fri, Dec 08, 2000 at 11:31:30AM -0800, Cliff Woolley wrote:
...
Since ap_bucket_split_any() is what we agree on, then let's move on and
figure out
what the best approach is to improving it to handle sockets and pipes better.
It
really is too bad that the read() function ignores the len
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2000 5:33 PM
+1 from me! get that big beast outta APR
I'm not sure about nuking stuff in the repository, though. Since OtherBill
shoved the mess into the repository before the last alpha (bad!), they have
now been
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2000 5:14 PM
Then the header name at the very least needs to change. As it is now, if
we install Apache on a machine that already has sdbm, we will break things
horribly.
Well, that's always been the case :-)
Hmm.
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2000 7:54 PM
One last observation, sdbm.h does _not_ belong in apr-util/include/ and
neither
does the apu_private stuff. Suggest we move those on out of there, but
where?
There are three locations that
On Sat, Dec 09, 2000 at 12:40:46AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2000 5:47 PM
note absurdity of apr_dbm_freedatum in a pool-managed implementation
The returned data is not always located in a pool.
On Sat, Dec 09, 2000 at 12:50:31AM -0600, William A. Rowe, Jr. wrote:
...
So if we can agree that apr-util is a collection of many 'library' like
features,
none of which warrent a full blown library on their own, then I'm +1 to loose
the src/ layer of apr-util, and let them pick and choose
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 09, 2000 1:17 AM
On Sat, Dec 09, 2000 at 12:40:46AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2000 5:47 PM
And no... don't suggest we copy the
On Sat, Dec 09, 2000 at 01:25:26AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 09, 2000 1:17 AM
On Sat, Dec 09, 2000 at 12:40:46AM -0600, William A. Rowe, Jr. wrote:
From: Greg Stein [mailto:[EMAIL PROTECTED]
Sent:
The use of which in buildconf.sh is breaking BeOS. Any objections if we
grabbed the PrintPath script from the build/ directory for Apache?
Someone did give me a replacement for which which worked but I can't
remember what it was :)
david
apr-util won't build on BeOS at present because Libtool doesn't allow
undefined references. This is a problem I've been having on other projects,
and it's in fact bogus on gcc versions of BeOS (Intel R4 and beyond) but is
totally valid on Power PC.
Which references are undefined, and why?
Argh! Can we please stop mucking with CVS directly? I have just tried to
update my tree, and my update is full of errors because we are mucking
with the repository directly. I understand why we are changing the
repository directly, but can we stop now.
Ryan
13 matches
Mail list logo