Michael Tuexen <[EMAIL PROTECTED]> writes:
> the check for socklen_t fails incorrectly because socklen_t is
> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.
Let's figure this out in HEAD first and then put it into 1.8.1.
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FA
Here it is -- I noticed while poking around earlier that the thing it
doesn't like is <#winder...> -- it was apparently expecting to call
cadr on it or something like that -- been kinda busy at work, so I
haven't had time to look into it. (I had to insert an abort after expanding
the ASSERT_SYNTAX
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
> ERROR: In procedure memoization:
> ERROR: Bad binding (e) in expression (letrec ((genmatch (lambda (x clauses
> match-expr) (let*
> ((length>= #) # (blist #)
> (plist #) (c
I wonder if this might be related to a change I made recently in the
ar
In article <[EMAIL PROTECTED]>, Marius Vollmer <[EMAIL PROTECTED]> wrote:
>Michael Tuexen <[EMAIL PROTECTED]> writes:
>
>> the check for socklen_t fails incorrectly because socklen_t is
>> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.
>
>What happens after the check fails?
This ist the problem, that the configure script does not figure out
that socklen_t does exist. Therefore it defines it when it is defined
in sys/socket.h the compiler throws an error.
Please use the code in configure.in which I posted earlier. Then it will
work.
Best regards
Michael
On Feb 17,
Mike Gran tells me that the way around the MacIntel gmp problem is to
configure with host=none-unknown-darwin7.1.0. I must have missed that
in the gmp instructions. Anyway, given gmp, the Guile 1.7.91 build chugs
away until
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall -Wmissing-prot
The good news is that Guile builds and works on MacIntel. The bad news...
Guile needs either support for netBSD's readline, or a way to disable readline
in configure. As it is, we get:
ld: Undefined symbols:
__rl_init_argument
__rl_kill_kbd_macro
_free_undo_list
_rl_clear_message
_rl_get_keymap
I may be chasing pure randomness, but I find that the only file that cannot
be compiled -O2 is read.c -- I can switch back and forth between the segfault
and the stack overflow just by changing the optimization switch on that
file (optimizing all the rest).
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> If that's gcc 4 then it might be the same thing afflicting i386 under
> -O3, that ceval/deval end up using a lot of stack. Try increasing the
> stack limit, ie. the guile one, wherever the default for that hides in
> the sources ...
Also, on PPC, I c
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
>
> So, I rebuilt guile using -g3
> ...
> : Stack overflow
If that's gcc 4 then it might be the same thing afflicting i386 under
-O3, that ceval/deval end up using a lot of stack. Try increasing the
stack limit, ie. the guile one, wherever the defau
Michael Tuexen <[EMAIL PROTECTED]> writes:
> the check for socklen_t fails incorrectly because socklen_t is
> defined in /sys/socket.h on Mac OS X, and on BSD systems in general.
What happens after the check fails? Will Guile compile correctly
anyway?
(I tried 1.7.90 on a friends Powerbook. It
Andy Wingo says:
> I once did some painful CVS bisection, which for the compiler flags I was
> using brought it back to the introduction of the inline keyword in 2002
> or something.
Perhaps you're on to something -- the "inline" business reminded me of
the old pstate bug where a variable was bein
[EMAIL PROTECTED] (Han-Wen Nienhuys) writes:
> what is your plan for maintaining the branches?
The release-1-6 branch remains stable of course, and the release-1-8
branch will be stable after 1.8.0 has been released, and is now in
feature freeze. "Stable" should mean "we try very hard to not
reg
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>> Well, they get to choose both texts that have a MD5 collision.
>> Looking at the PostScript source reveals that the texts have been
>> rigged, which should be enough if this goes to court. In our case, an
>> attacker would need to find a second meani
Marius Vollmer <[EMAIL PROTECTED]> writes:
> We are pleased to announce the release of Guile 1.7.91. This is a
> release candidate for Guile 1.8. It can be found here:
BTW, maybe you should also announce it on [EMAIL PROTECTED]' (which is
relayed as the `gnu.announce' newsgroup).
Thanks,
Ludov
Hi,
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
> filesys.c:860: error: `NAME_MAX' undeclared (first use in this function)
GNU (aka. GNU/Hurd) may very well have the same problem. (arbitrary
limitations like this or `PATH_MAX' are not supported[0]) Can somebody
check this?
Thanks,
Ludovic.
Hi,
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Well, they get to choose both texts that have a MD5 collision.
> Looking at the PostScript source reveals that the texts have been
> rigged, which should be enough if this goes to court. In our case, an
> attacker would need to find a second meani
Hi,
On Mon, 2006-02-13 at 07:31 -0800, Bill Schottstaedt wrote:
> In Linux FC4 dual x86-64, trying to build Guile 1.7.91 I get:
This is
http://lists.gnu.org/archive/html/guile-devel/2005-12/msg00048.html. I
once did some painful CVS bisection, which for the compiler flags I was
using brought it b
Oops, I see opendir doesn't record the opened directoryname. Hmm. It
might be easiest for now to just stick a mutex around plain readdir()
and worry later about readdir_r and its buffer size.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lis
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
>
> I found some examples by Googling for readdir_r and _PC_NAME_MAX.
Incomplete bit of code below, it's not pretty but I guess it's what
has to be done.
#if HAVE_READDIR_R
/* On Solaris 2.7, struct dirent only contains "char d_name[1]" and the
Yes, here's the relevent portion of man readdir_r:
The caller must allocate storage pointed to by entry to be
large enough for a dirent structure with an array of char
d_name member containing at least NAME_MAX (that is,
pathconf(directory, _PC_NAME_MAX)) plus on
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
>
> (The d_name field is still defined to be 1 char long, so I think the
> glibc comment still pertains to Solaris,
I guess that means you can't just define a struct. What does the
readdir_r man page say you should do? pathconf like you said?
___
I don't think NAME_MAX is defined anywhere -- the documentation says
you should use pathconf instead. Here's the portion of limits.h where
they commented out NAME_MAX:
/*
* POSIX 1003.1a, section 2.9.5, table 2-5 contains [NAME_MAX] and the
* related text states:
*
* A definition of one of th
"Bill Schottstaedt" <[EMAIL PROTECTED]> writes:
>
> filesys.c:860: error: `NAME_MAX' undeclared (first use in this function)
>
> union {
> struct dirent ent;
> char pad1 [sizeof(struct dirent) + NAME_MAX];
> char pad2 [offsetof (struct dirent, d_name) + NAME_MAX + 1];
This is
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> BTW, I'd strongly recommend using SHA1 sums (e.g., via `sha1sum', part
> of GNU Coreutils) rather than MD5.
Yeah, that's probably best.
> See the example at http://www.cits.rub.de/MD5Collisions/ if in
> doubt. ;-)
Well, they get to choose both text
I was trying to build the new guile on a MacIntel box, got this error in gmp:
tmp-dive_1.s:98:invalid character '@' in first operand
make[2]: *** [dive_1.lo] Error 1
I sent a bug report to the gmp bug list and got this reply:
Date: 13 Feb 2006 17:26:45 +0100
From: Torbjorn Granl
In Linux FC4 dual x86-64, trying to build Guile 1.7.91 I get:
creating guile
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc
continuations.doc
debug.doc deprecation.doc deprecated.doc discouraged.doc dynl.doc dynwind.doc
environments
.doc eq.doc error.doc eval.doc evale
In solaris 10, I think the readdir_r usage is incorrect.
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -g -O2 -Wall -Wmissing-prototypes
-MT filesys.lo -MD -
MP -MF .deps/filesy
s.Tpo -c filesys.c -fPIC -DPIC -o .libs/filesys.o
filesys.c: In function `scm_readdir':
filesys.c:860: error: `NAME_MAX'
Hi,
Marius Vollmer <[EMAIL PROTECTED]> writes:
> We are pleased to announce the release of Guile 1.7.91. This is a
> release candidate for Guile 1.8. It can be found here:
>
> ftp://alpha.gnu.org/gnu/guile/guile-1.7.91.tar.gz
FYI, on `powerpc-unknown-linux-gnu', everything seems to work fi
Hi Marius,
the check for socklen_t fails incorrectly because socklen_t is
defined in /sys/socket.h on Mac OS X, and on BSD systems in general.
What about using
AC_MSG_CHECKING(for socklen_t)
AC_TRY_COMPILE([#ifdef HAVE_SYS_TYPES_H
#include
#endif
We are pleased to announce the release of Guile 1.7.91. This is a
release candidate for Guile 1.8. It can be found here:
ftp://alpha.gnu.org/gnu/guile/guile-1.7.91.tar.gz
Its MD5 checksum is
b2106c1b574e22ec67c4c2178074b5ec guile-1.7.91.tar.gz
The plan is to release version 1.8.0 nex
31 matches
Mail list logo
