More problems on HP-UX

More problems on HP-UX

[Andreas Vögele]

After several weeks of frustration with various Scheme implementations 
I've decided to go back to Python. I was able to build Guile 1.6.4 on 
several but building Guile CVS on HP-UX und Mac OS X is a nightmare. 
Here are a couple of warnings and errors that I get when building Guile 
CVS with GCC 3.3.2 on HP-UX.

Bye,
Andreas

1.

continuations.c: In function `scm_dynthrow':
continuations.c:269: warning: implicit declaration of function 
`SCM_PTR_GE'

The macro SCM_PTR_GE doesn't exist anymore.

2.

threads.c: In function `scm_threads_mark_stacks':
threads.c:977: error: `sizet' undeclared (first use in this function)
threads.c:977: error: (Each undeclared identifier is reported only once
threads.c:977: error: for each function it appears in.)
threads.c:977: warning: left-hand operand of comma expression has no 
effect
threads.c:977: error: parse error before "stack_len"
threads.c:977: error: too few arguments to function `scm_mark_locations'

3.

stime.c: In function `scm_gmtime':
stime.c:424: warning: implicit declaration of function `gmtime_r'
stime.c:424: warning: assignment makes pointer from integer without a 
cast

On HP-UX, the gmtime_r() prototype isn't declared unless 
-D_POSIX_C_SOURCE=199506L is passed to the C compiler.

4.

It seems that alloca.h must be included on HP-UX even when Guile is 
built with GCC.

eval.c: In function `deval':
eval.c:2910: warning: implicit declaration of function `alloca'

5.

gc_os_dep.c: In function `scm_get_stack_base':
gc_os_dep.c:1881: warning: unused variable `result'

GCC 3.3.2 seems to be too smart for the initialization in gc_os_dep.c.

6.

I think that the following warnings are caused by a bug in GCC 3.3.2. 
According to my copy of "Programming in C" it should be okay to pass a 
char instead of an int to iscntrl() etc.

backtrace.c: In function `display_frame_expr':
backtrace.c:403: warning: subscript has type `char'

numbers.c: In function `mem2uinteger':
numbers.c:2337: warning: subscript has type `char'
numbers.c:2339: warning: subscript has type `char'
numbers.c:2348: warning: subscript has type `char'
numbers.c:2352: warning: subscript has type `char'
numbers.c: In function `mem2decimal_from_point':
numbers.c:2425: warning: subscript has type `char'
numbers.c:2506: warning: subscript has type `char'
numbers.c:2514: warning: subscript has type `char'
numbers.c: In function `mem2ureal':
numbers.c:2592: warning: subscript has type `char'

7.

I can now link Guile but I get the following runtime error message:

Internal error: Need to upgrade mutex size



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 3

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> On HP-UX, the gmtime_r() prototype isn't declared unless
> -D_POSIX_C_SOURCE=199506L is passed to the C compiler.

Thanks, I added that.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 3

[Andreas Vögele]

Am 28.04.2004 um 00:41 schrieb Kevin Ryde:

> Andreas Vögele <voegelas@gmx.net> writes:
>>
>> On HP-UX, the gmtime_r() prototype isn't declared unless
>> -D_POSIX_C_SOURCE=199506L is passed to the C compiler.
>
> Thanks, I added that.

_POSIX_C_SOURCE is also required in libguile/filesys.c for readdir_r(). 
  Wouldn't it be better to change configure.in instead of the source 
files?

AC_CANONICAL_HOST

# On HP-UX, _POSIX_C_SOURCE must be defined to 199506L to get prototypes
# for reentrant functions like gmtime_r(), readdir_r() etc.
case "$host" in
   *-*-hpux* )
     CFLAGS="$CFLAGS -D_POSIX_C_SOURCE=199506L"
   ;;
esac

Currently, I can't build Guile CVS since autogen.sh fails on HP-UX as 
well as on Debian Woody (with autoconf and automake from 
backports.org). It get the error message "possible undefined macro: 
AM_INIT_AUTOMAKE".



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 3

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> _POSIX_C_SOURCE is also required in libguile/filesys.c for
> readdir_r().

Beaut.

> Wouldn't it be better to change configure.in instead of
> the source files?

glibc advises putting it in the source file, so they're
self-contained.  I think that's the way these defines are meant to be
used.  It might be different if every single file needed something.

> Currently, I can't build Guile CVS since autogen.sh fails on HP-UX as
> well as on Debian Woody (with autoconf and automake from
> backports.org). It get the error message "possible undefined macro:
> AM_INIT_AUTOMAKE".

Usually that's from not re-running aclocal.  autoreconf in autogen.sh
might be meant to do that, but I always do it manually.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 3

[Andreas Vögele]

Kevin Ryde writes:

>> Wouldn't it be better to change configure.in instead of
>> the source files?
>
> glibc advises putting it in the source file, so they're
> self-contained.  I think that's the way these defines are meant to be
> used.  It might be different if every single file needed something.

But it's more robust to define _POSIX_C_SOURCE in configure.in since 
developers who don't work on HP-UX don't have to remember to put the 
definition at the top of files that use reentrant functions.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 3

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> But it's more robust to define _POSIX_C_SOURCE in configure.in since
> developers who don't work on HP-UX don't have to remember to put the
> definition at the top of files that use reentrant functions.

I believe it's not hpux specific but in theory applies everywhere,
depending what the defaults for the libc are.  glibc insulates one
from such things, mostly.

CFLAGS is not a good place, since mucking about with flags in
configure is always best avoided if possible.  But _scm.h or config.h
would be possibilities, especially as I say if it's wanted just about
everywhere.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 7

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> I can now link Guile but I get the following runtime error message:
>
> Internal error: Need to upgrade mutex size

Thanks.  There's a hard coded maximum size expected of a mutex in the
pluggable threads support stuff.  On a hpux11 in 32-bit mode I see
pthread_mutex_t is 88 bytes.  Is that what you get?


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 7

[Andreas Vögele]

Kevin Ryde writes:

> Andreas Vögele <voegelas@gmx.net> writes:
>>
>> I can now link Guile but I get the following runtime error message:
>>
>> Internal error: Need to upgrade mutex size
>
> Thanks.  There's a hard coded maximum size expected of a mutex in the
> pluggable threads support stuff.  On a hpux11 in 32-bit mode I see
> pthread_mutex_t is 88 bytes.  Is that what you get?

Yes, that's what I get too.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 6

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> I think that the following warnings are caused by a bug in GCC
> 3.3.2.

No it arises from ctype.h supplied by your good friends at hp.

> According to my copy of "Programming in C" it should be okay to
> pass a char instead of an int to iscntrl() etc.

I think it was meant to be an int.  But if you're in 7-bit ascii then
it doesn't make a difference.

> backtrace.c: In function `display_frame_expr':
> backtrace.c:403: warning: subscript has type `char'
>
> numbers.c: In function `mem2uinteger':
> numbers.c:2337: warning: subscript has type `char'
> ...

Thanks, I'll add some casts to "int".  They definitely want casts
through "unsigned char", to protect against 8-bit values.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 6

[Andreas Vögele]

Kevin Ryde writes:

>> According to my copy of "Programming in C" it should be okay to
>> pass a char instead of an int to iscntrl() etc.
>
> I think it was meant to be an int.  But if you're in 7-bit ascii then
> it doesn't make a difference.

Yes, but my German copy of "Programming in C, 2nd ed" says in section 
A.6.1: "A character [...] can be used everywhere in an expression where 
an integer object is required. [...]". And according to section A.7.3, 
subscript array references are expressions.

>> backtrace.c: In function `display_frame_expr':
>> backtrace.c:403: warning: subscript has type `char'
>>
>> numbers.c: In function `mem2uinteger':
>> numbers.c:2337: warning: subscript has type `char'
>> ...
>
> Thanks, I'll add some casts to "int".  They definitely want casts
> through "unsigned char", to protect against 8-bit values.

When I googled for the "subscripts has type char" problem I found a 
statement that says that casts to "int" could "cause problems" on other 
systems. Whatever that means.

Since the build only aborts if --enable-maintainer-mode, i.e. -Werror, 
is enabled I'd probably keep the "char" values. BTW, I use only one 
cast to fix this problem (in backtrace.c). In numbers.c I  changed the 
type of the variables to "int".



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 6

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> Yes, but my German copy of "Programming in C, 2nd ed" says in section
> A.6.1: "A character [...] can be used everywhere in an expression
> where an integer object is required. [...]". And according to section
> A.7.3, subscript array references are expressions.

gcc being overly enthusiastic about warnings I suppose.

> Since the build only aborts if --enable-maintainer-mode, i.e. -Werror,
> is enabled I'd probably keep the "char" values. BTW, I use only one
> cast to fix this problem (in backtrace.c). In numbers.c I  changed the
> type of the variables to "int".

That would also work, but you do need to cast through unsigned char,
so 8-bit char values don't become negative ints, which are not
accepted by c99 ctype.h (though glibc is forgiving of them).


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 4

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> It seems that alloca.h must be included on HP-UX even when Guile is
> built with GCC.
>
> eval.c: In function `deval':
> eval.c:2910: warning: implicit declaration of function `alloca'

That's odd, it's meant to be a builtin outside of strict c89 or c99
mode.

A #define to __builtin_alloca might be better than alloca.h.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 4

[Andreas Vögele]

Kevin Ryde writes:

> Andreas Vögele <voegelas@gmx.net> writes:
>>
>> It seems that alloca.h must be included on HP-UX even when Guile is
>> built with GCC.
>>
>> eval.c: In function `deval':
>> eval.c:2910: warning: implicit declaration of function `alloca'
>
> That's odd, it's meant to be a builtin outside of strict c89 or c99
> mode.

__builtin_alloca is available but not alloca.

Actually, /usr/include/alloca.h contains the following lines on HP-UX:

#ifndef alloca
#  define alloca(x) __builtin_alloca(x)
#endif

> A #define to __builtin_alloca might be better than alloca.h.

Yes, that's much better than to rely on the fact that GCC and HP's 
compiler happen to provide the same builtin.

Moreover, it seems that the alloca problem isn't HP specific at all. I 
also get a warning when I compile the following program under Mac OS X 
with GCC 3.3 and -Wall:

int
main(void)
{
         char *p = alloca (20);
         *p = 0;
         return 0;
}

allocatest.c: In function `main':
allocatest.c:4: warning: implicit declaration of function `alloca'

What about the following code?

#ifndef __GNUC__
...
#else
# ifndef alloca
#  define alloca(x) __builtin_alloca(x)
# endif
#endif



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 4

[Andreas Vögele]

[-- Attachment #1.1.1: Type: text/plain, Size: 496 bytes --]

Am 28.04.2004 um 09:43 schrieb Andreas Vögele:

> Kevin Ryde writes:
>
>> Andreas Vögele <voegelas@gmx.net> writes:
>>>
>>> It seems that alloca.h must be included on HP-UX even when Guile is
>>> built with GCC.
>>>
>>> eval.c: In function `deval':
>>> eval.c:2910: warning: implicit declaration of function `alloca'
>>
>> That's odd, it's meant to be a builtin outside of strict c89 or c99
>> mode.

Here's the patch that I use. I'll look at the remaining problems 
tomorrow.


[-- Attachment #1.1.2: eval.c.diff --]
[-- Type: application/octet-stream, Size: 613 bytes --]

Index: eval.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/eval.c,v
retrieving revision 1.363
diff -u -r1.363 eval.c
--- eval.c	26 Apr 2004 19:59:03 -0000	1.363
+++ eval.c	28 Apr 2004 21:21:18 -0000
@@ -38,7 +38,11 @@
 /* AIX requires this to be the first thing in the file.  The #pragma
    directive is indented so pre-ANSI compilers will ignore it, rather
    than choke on it.  */
-#ifndef __GNUC__
+#ifdef __GNUC__
+# ifndef alloca
+#  define alloca __builtin_alloca
+# endif
+#else
 # if HAVE_ALLOCA_H
 #  include <alloca.h>
 # else

[-- Attachment #1.1.3: Type: text/plain, Size: 1 bytes --]



[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1846 bytes --]

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 4

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> Here's the patch that I use.

Hmm.  I don't really want to make that change.  What's there now is
what autoconf recommends, and I'd rather see it changed in autoconf
first.  That's if a change is needed, since what you report
contradicts what the gcc manual says about alloca being a builtin.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 4

[Andreas Vögele]

Kevin Ryde writes:

> Andreas Vögele <voegelas@gmx.net> writes:
>>
>> Here's the patch that I use.
>
> Hmm.  I don't really want to make that change.  What's there now is 
> what autoconf recommends, and I'd rather see it changed in autoconf 
> first.
>
> That's if a change is needed, since what you report contradicts what 
> the gcc manual says about alloca being a builtin.

alloca() may be built in but recent versions of GCC require a function 
declaration. For example, GCC 2.95 compiles the following code without 
printing a warning since strlen() is built in. On the other hand, GCC 
3.3 will output a warning if the compiler option -Wall is used and 
<string.h> is not included.

int main(void)
{
   return strlen ("hello, world");
}

The same applies to alloca(). The code recommendation for alloca() in 
the section "Particular Function Checks" of the Autoconf manual isn't 
up-to-date. If __GNUC__ is defined the code does not make sure that 
alloca() is declared.

The easiest solution is to change the recommended code so that 
__builtin_alloca() is used if __GNUC_ is defined. If the '__builtin_' 
function is used no declaration is required. You can verify this by 
replacing strlen() with __builtin_strlen() in the above example.

#ifdef __GNUC__
# define alloca(x) __builtin_alloca(x)
#else
# if HAVE_ALLOCA_H
... /* remaining code from the Autoconf manual */
# endif
#endif

BTW, building Guile with GCC 3.3 does not fail on glibc-based systems 
since stdlib.h includes alloca.h. But there are systems where alloca.h 
is not included by stdlib.h.

As far as I can see, eval.c is the  only place in Guile where alloca() 
is used. Wouldn't it be possible to get rid of alloca()? According to 
the comp.lang.c FAQ the use of alloca() is discouraged anyway 
(http://www.eskimo.com/~scs/C-faq/q7.32.html).

Re: More problems on HP-UX ... 1

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> continuations.c: In function `scm_dynthrow':
> continuations.c:269: warning: implicit declaration of function
> `SCM_PTR_GE'
>
> The macro SCM_PTR_GE doesn't exist anymore.

What should it be, just >= these days?


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 1

[Andreas Vögele]

Kevin Ryde write:

> Andreas Vögele <voegelas@gmx.net> writes:
>>
>> continuations.c: In function `scm_dynthrow':
>> continuations.c:269: warning: implicit declaration of function
>> `SCM_PTR_GE'
>>
>> The macro SCM_PTR_GE doesn't exist anymore.
>
> What should it be, just >= these days?

I'm not sure since I couldn't test scm_dynthrow(). Probably, the code 
in the #if part should be similar to the code in the #else part but 
with + instead of - and >= instead of <=. dst is used in 
copy_stack_and_call() at the bottom of scm_dynthrow().



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 1

[Andreas Vögele]

[-- Attachment #1.1.1: Type: text/plain, Size: 423 bytes --]

Am 28.04.2004 um 08:10 schrieb Andreas Vögele:

> Kevin Ryde writes:
>
>> Andreas Vögele <voegelas@gmx.net> writes:
>>>
>>> continuations.c: In function `scm_dynthrow':
>>> continuations.c:269: warning: implicit declaration of function
>>> `SCM_PTR_GE'
>>>
>>> The macro SCM_PTR_GE doesn't exist anymore.
>>
>> What should it be, just >= these days?

Yes, just >=.

BTW, I'm now subscribed to bug-guile.


[-- Attachment #1.1.2: continuations.c.diff --]
[-- Type: application/octet-stream, Size: 616 bytes --]

Index: continuations.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/continuations.c,v
retrieving revision 1.52
diff -u -r1.52 continuations.c
--- continuations.c	7 Jan 2004 20:21:30 -0000	1.52
+++ continuations.c	28 Apr 2004 21:21:45 -0000
@@ -266,7 +266,7 @@
   SCM_STACKITEM stack_top_element;
 
 #if SCM_STACK_GROWS_UP
-  if (SCM_PTR_GE (dst + continuation->num_stack_items, &stack_top_element))
+  if (dst + continuation->num_stack_items >= &stack_top_element)
     grow_stack (cont, val);
 #else
   dst -= continuation->num_stack_items;

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1846 bytes --]

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 2

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> threads.c: In function `scm_threads_mark_stacks':
> threads.c:977: error: `sizet' undeclared (first use in this function)

Thanks.  Hmm.  It's either meant to be size_t or scm_sizet I presume.
I'll change it to size_t.

Is this also a problem in 1.6, or did you say that worked?  (It looks
like it's in coop-threads.c.)


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 2

[Andreas Vögele]

Kevin Ryde writes:

> Andreas Vögele <voegelas@gmx.net> writes:
>>
>> threads.c: In function `scm_threads_mark_stacks':
>> threads.c:977: error: `sizet' undeclared (first use in this function)
>
> Thanks.  Hmm.  It's either meant to be size_t or scm_sizet I presume.
> I'll change it to size_t.

The number of arguments is also wrong:
scm_mark_locations (((size_t) t->base, (size_t) stack_len));
vs.
scm_mark_locations (SCM_STACK_PTR (&t), stack_len);
in the #else part.

I think that the wrong call has to be replaced with one of the 
following calls. But which one?

scm_mark_locations (SCM_STACK_PTR (&t), stack_len);
scm_mark_locations (SCM_STACK_PTR (&t), (size_t) t->base + (size_t) 
stack_len);
scm_mark_locations (SCM_STACK_PTR (&t), (size_t) t->base - (size_t) 
stack_len);

> Is this also a problem in 1.6, or did you say that worked?  (It looks
> like it's in coop-threads.c.

I was able to build 1.6 and run the test suite as well as all my 
programs, which don't use threads.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 2

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> I think that the wrong call has to be replaced with one of the
> following calls.

Ah yes.

> But which one?

Dunno.  Do we have an expert here who can say?

t->base is the low address for an upward growing stack is it?, which
would mean it's just the cast which is wrong perhaps?

	scm_mark_locations (t->base, stack_len);


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 2

[Kevin Ryde]

I wrote:
>
> 	scm_mark_locations (t->base, stack_len);

I made this change (in the head) because it looks right.  I tried to
test it on a hppa debian, but it hung at startup in
scm_lt_dlpreload_default :(.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... 2

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

>> But which one?
>
> Dunno.  Do we have an expert here who can say?
>
> 	scm_mark_locations (t->base, stack_len);

That's the correct one (in case you are still interested ;-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... macos

[Kevin Ryde]

Andreas Vögele <voegelas@gmx.net> writes:
>
> but building Guile CVS on HP-UX und Mac OS X is a nightmare.

On darwin5.5 for me it compiles, but doesn't run

	ERROR: In procedure list:
	ERROR: #<unknown port>:1:6: end of file
	test-system-cmds: system exit status was 2 rather than 42
	FAIL: test-system-cmds
	cannot determine stack base!
	FAIL: test-num2integral


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: More problems on HP-UX ... macos

[Andreas Vögele]

Am 28.04.2004 um 02:36 schrieb Kevin Ryde:

> Andreas Vögele <voegelas@gmx.net> writes:
>>
>> but building Guile CVS on HP-UX und Mac OS X is a nightmare.
>
> On darwin5.5 for me it compiles, but doesn't run
>
> 	ERROR: In procedure list:
> 	ERROR: #<unknown port>:1:6: end of file
> 	test-system-cmds: system exit status was 2 rather than 42
> 	FAIL: test-system-cmds
> 	cannot determine stack base!
> 	FAIL: test-num2integral

That's what I also get on Panther, i.e. Darwin 7.3.0 when I run "make 
check"



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile