Mandrake is rpm-based:
$ rpm -q make bash
I think the make version might actually be the most important part.
I know, but I remove all rpm's just after installing Linux, and re-install
most of the system by hand. I dislike using rpms whenever possible.
Masochistic,
On Sat, Dec 02, 2000 at 04:19:13PM -0800, [EMAIL PROTECTED] wrote:
...
Yep. Quick question for you now, why does the top-level Makefile have:
SUBDIRS = src . test build
It seems to me this should be:
SUBDIRTS = src test
We aren't building anything in build or . are we?
. is there
On Sat, Dec 02, 2000 at 11:45:37PM -, [EMAIL PROTECTED] wrote:
rbb 00/12/02 15:45:37
Modified:shmem/unix shmem.c
Log:
Fix a compile break on BeOS and FreeBSD. We don't want to add the size
of the void *, we want to add the size of the apr_shmem_t * variable.
Whee!
We aren't building anything in build or . are we?
. is there because we build the library. It is ordered after the src
subdirectory.
build is there so we can recurse on the various clean targets.
Note that test is there primarily for the clean targets, too. We probably
don't want to
Q. Now that APRUTIL exists, may we please move hooks (a
generally useful
entity) into that lib (and put this issue back into util?
I think we are just waiting for some people on dev to decide how to move
the code out of Apache and into apr-utils. Greg and I have both voted
First of all, Sam could you please post patches in line? It makes them
much easier to reply to. Thanks.
Now, quick question.
Index: network_io/beos/Makefile.in
===
RCS file: /home/cvspublic/apr/network_io/beos/Makefile.in,v
Second question about this patch,
Index: include/apr_lib.h
===
RCS file: /home/cvspublic/apr/include/apr_lib.h,v
retrieving revision 1.44
diff -u -r1.44 apr_lib.h
--- include/apr_lib.h 2000/11/26 03:00:01 1.44
+++
On Sat, Dec 02, 2000 at 11:40:37PM -0800, [EMAIL PROTECTED] wrote:
Second question about this patch,
Index: include/apr_lib.h
===
RCS file: /home/cvspublic/apr/include/apr_lib.h,v
retrieving revision 1.44
diff -u -r1.44
On Sun, Dec 03, 2000 at 02:10:08AM -0600, Sam TH wrote:
...
--- apr_lib.h 2000/11/26 03:00:01 1.44
+++ apr_lib.h 2000/12/03 08:09:37
@@ -113,6 +113,9 @@
#define apr_isdigit(c) (isdigit(((unsigned char)(c
#define apr_isgraph(c) (isgraph(((unsigned char)(c
#define apr_islower(c)
On Sun, Dec 03, 2000 at 03:39:12AM -0600, Sam TH wrote:
On Sun, Dec 03, 2000 at 01:26:28AM -0800, Greg Stein wrote:
Looks like Ryan is offline, so I'll go and commit the isascii fix. I'm not
sure on the include header stuff, though, so I'm going to pass that one up.
Well, if you look at
Applied. Thanks!
On Sun, Dec 03, 2000 at 02:10:08AM -0600, Sam TH wrote:
...
--- apr_lib.h 2000/11/26 03:00:01 1.44
+++ apr_lib.h 2000/12/03 08:09:37
@@ -113,6 +113,9 @@
#define apr_isdigit(c) (isdigit(((unsigned char)(c
#define apr_isgraph(c) (isgraph(((unsigned char)(c
On Sun, Dec 03, 2000 at 02:11:43AM -0800, Greg Stein wrote:
On Sun, Dec 03, 2000 at 03:39:12AM -0600, Sam TH wrote:
On Sun, Dec 03, 2000 at 01:26:28AM -0800, Greg Stein wrote:
Looks like Ryan is offline, so I'll go and commit the isascii fix. I'm not
sure on the include header stuff,
Gotcha! The patch to unix/sockaddr.c has been applied (rather than the
Makefile.in change)
Cheers,
-g
On Sun, Dec 03, 2000 at 04:52:45AM -0600, Sam TH wrote:
...
Here's the include chain.
network_io/beos/sockaddr.c
includes
network_io/unix/sockaddr.c
includes
On Sun, Dec 03, 2000 at 10:11:43AM -, [EMAIL PROTECTED] wrote:
gstein 00/12/03 02:11:43
Modified:include apr_lib.h
Log:
isascii() is not available on PowerPC versions of BeOS. Supply a definition.
This still doesn't work. It turns out that neither BEOS nor
__POWER_PC__
On Sun, Dec 03, 2000 at 07:42:55AM -0600, Sam TH wrote:
On Sun, Dec 03, 2000 at 10:11:43AM -, [EMAIL PROTECTED] wrote:
gstein 00/12/03 02:11:43
Modified:include apr_lib.h
Log:
isascii() is not available on PowerPC versions of BeOS. Supply a
definition.
This
Hopefully I didn't miss any comments on the mailing list last night
(where is that archive again?).
Here is enough to look at to make sure I didn't screw anything up. I
added family and type parameters too so that APR doesn't have to bend
over backwards (i.e., use syscalls) to find that out. We
Jeff Trawick [EMAIL PROTECTED] writes:
+apr_status_t apr_make_os_sock(apr_socket_t **apr_sock, apr_os_sock_t
*os_sock,
+ struct sockaddr *local, struct sockaddr
*remote,
+ int family, int type, apr_pool_t *cont)
+{
...
+
Don't worry about it... we'll get a solution worked out. I got the
impression David was looking into it :-)
I've just committed a patch that should fix this. If we don't have isascii
we don't really need to define it as we'll just hide it in apr_isascii, so
we just define apr_isascii
First of all, Sam could you please post patches in line? It makes them
much easier to reply to. Thanks.
Sure. Sorry about that.
No problem, information like this needs to go on the site, I'll try
to update it all today. :-)
INCDIR=../../include
OSDIR=$(INCDIR)/arch/@OSDIR@
Sam, can you cvs update and try the fix I committed? Thanks.
david
This still doesn't work. It turns out that neither BEOS nor
__POWER_PC__ is defined at the point in Subversion that this gets used
and likely not in other APR-using apps either. So, new patch, using
HAVE_isascii, which doesn't require including apr_private.h, despite
Ryan's worry. Also,
On Sun, Dec 03, 2000 at 04:08:50PM -, David Reid wrote:
Sam, can you cvs update and try the fix I committed? Thanks.
Looks like it works. So APR appears not to have any obvious
difficulties on my end. :-)
Thanks lots
sam th
[EMAIL PROTECTED]
On Sun, 3 Dec 2000, Sam TH wrote:
On Sun, Dec 03, 2000 at 04:08:50PM -, David Reid wrote:
Sam, can you cvs update and try the fix I committed? Thanks.
Looks like it works. So APR appears not to have any obvious
difficulties on my end. :-)
Great! Can you try running the test
On Sun, 3 Dec 2000, Jeff Trawick wrote:
Hopefully I didn't miss any comments on the mailing list last night
(where is that archive again?).
Here is enough to look at to make sure I didn't screw anything up. I
added family and type parameters too so that APR doesn't have to bend
over
On Sun, Dec 03, 2000 at 08:21:35AM -0800, [EMAIL PROTECTED] wrote:
This still doesn't work. It turns out that neither BEOS nor
__POWER_PC__ is defined at the point in Subversion that this gets used
and likely not in other APR-using apps either. So, new patch, using
HAVE_isascii, which
Well I knew that was coming :)
There are a few problems with some of the test programs but as they've been
so low on the priority list of things to do I haven't fixed them for BeOS.
Looks like I'll have to get to them now doesn't it? :)
david
As for the tests, there were a bunch of type mismatches, virtually all
related to the signedness of character strings. Then there was the
The type problems probably shouldn't be solved with a cast. This is
happening because we changed a bunch on arguments from apr_ssize_t to
apr_size_t in
On Sun, Dec 03, 2000 at 09:42:22AM -0800, [EMAIL PROTECTED] wrote:
The type problems probably shouldn't be solved with a cast. This is
happening because we changed a bunch on arguments from apr_ssize_t to
apr_size_t in the function prototypes, but neglected to update the
tests. We need to
After that, the only proble was testdso, which is a dynamically loaded
binary. Naturally the syntax didn't translate well, so I just
commented it out entirely. However, this mean that I couldn't run
most of the tests. So, the upshot is, here's the test results:
What do you mean the
If we build APR in standalone mode do we read hints.m4? I ask as on BeOS
I'm seeing APR_FILES_AS_SOCKETS defined to 1 when it should be 0. We
normally do this via hints.m4 but I don't see it being used when we build
APR in standalone mode.
We don't currently read hints.m4 from APR's
What do you mean the syntax doesn't translate well? Does it compile at
all? Does it run? If this doesn't work on BeOS, we have real problems,
because we haven't accomplished our goal of a Portable Run-Time.
I meant the command line compiler option syntax, not the C syntax.
Naturally,
What do you mean the syntax doesn't translate well? Does it compile at
all? Does it run? If this doesn't work on BeOS, we have real problems,
because we haven't accomplished our goal of a Portable Run-Time.
The problem is that we don't have the logic in the Makefile for the test
For all the libtool illiterates :-)) out there, you might
want to consider reading autobook, a free book featuring two
chapters about libtool. The first one is directly applicable
to Apache and APR:
http://sources.redhat.com/autobook/
TOC:
[EMAIL PROTECTED] writes:
On Sun, 3 Dec 2000, Jeff Trawick wrote:
Hopefully I didn't miss any comments on the mailing list last night
(where is that archive again?).
Here is enough to look at to make sure I didn't screw anything up. I
added family and type parameters too so that
Here is enough to look at to make sure I didn't screw anything up. I
added family and type parameters too so that APR doesn't have to bend
over backwards (i.e., use syscalls) to find that out. We don't keep
the type anywhere yet but it is likely to become useful in the future.
On Sun, Dec 03, 2000 at 09:49:11AM -0800, [EMAIL PROTECTED] wrote:
What do you mean the syntax doesn't translate well? Does it compile at
all? Does it run? If this doesn't work on BeOS, we have real problems,
because we haven't accomplished our goal of a Portable Run-Time.
The
36 matches
Mail list logo
