Re: The Guile junk drawer and a C plea

I'll just add, as someone who works on packaging of guile in pkgsrc, that we have had to have multiple versions for a long time. There is software useful enough for people to want, with various requirements. Currently we have 1.8 2.0 2.2 3.0 If there were more concern about compatibility

Re: Add internal definitions to derived forms

Ludovic Courtès writes: > The reason I’m hesitant is that, while I think it’s nice to be able to > have local ‘define’ in these contexts, I’m wary of diverging from R5RS > and R6RS. Since it’s a one-way change (we won’t be able to revert it > once people rely on it), I thought we’d rather be car

Re: GNU Guile 3.0.9rc1 available for testing!

Ludovic Courtès writes: > So something like the patch below? > > Thanks, > Ludo’. > > diff --git a/libguile/posix.c b/libguile/posix.c > index 74c743119..0b1fe2637 100644 > --- a/libguile/posix.c > +++ b/libguile/posix.c > @@ -105,8 +105,8 @@ > # else > # define W_EXITCODE(ret, sig) ((ret) <

Re: GNU Guile 3.0.9rc1 available for testing!

Ludovic Courtès writes: > My understanding is that the expectation of being able to later mprotect > that mapping to make it writable is a valid one per POSIX. Quoth > : > > If PROT_WRITE is specified, the application sh

Re: GNU Guile 3.0.9rc1 available for testing!

Greg Troxel writes: > with or without -j2. I see ice-9/readline.scm in git but not in the > rc tarball. and, in guile-readline/Makefile.am I see if HAVE_READLINE SOURCES += ice-9/readline.scm and I don't see an else with EXTRA_DIST. I think it's a bug for make dist

Re: GNU Guile 3.0.9rc1 available for testing!

My second approach is using the rc tarball in pkgsrc. I had to patch out the verify call. pkgsrc already works around PaX issues mostly, via paxctl on things that do jit, after build and before use, and by --- libguile/loader.c.orig 2018-01-08 16:21:04.790894906 + +++ libguile/loade

Re: GNU Guile 3.0.9rc1 available for testing!

lloda writes: > This looks like https://debbugs.gnu.org/60971 > on mac os. Yes, it does. My quick reaction is that if the POSIX-required macros operation on system types that might be struct, then faking up ints for testing is unsound. Maybe only do verify if g

Re: GNU Guile 3.0.9rc1 available for testing!

Ludovic Courtès writes: > Hello Guilers! > > (Cc’ing packagers I know; feel free to ping other packagers!) I dropped the CC as I suspect all are on guile-devel. > Please report any issues you may find. I’m particularly interested in > portability regressions (NetBSD and other BSDs, macOS, MinG

Re: [PATCH] web: default to INADDR_ANY instead of INADDR_LOOPBACK

Aleix Conchillo Flaqué writes: >> Using INADDR_ANY instead of INADDR_LOOPBACK makes it convenient when >> starting the web server inside containers without the need to having to >> specify INADDR_ANY all the time. This is the default in most libraries >> and languages. I may be an outlier, but

Re: mmap for guile

Ludovic Courtès writes: > Greg Troxel skribis: > >> I have been meaning to try to build this under NetBSD, to check >> portability. I think the mmap code should by default rely only on what >> POSIX guarantees: >> https://pubs.opengroup.org/onlinepubs/

Re: mmap for guile

Ludovic Courtès writes: > Besides what Maxime points out, some more superficial issues: > > • In documentation, please refer to the relevant glibc section instead > of “See man page” (info "(libc) Memory-mapped I/O"). > > • Please update doc/ref with a section on memory-mapped I/O. > >

Re: GNU Guile 3.0.8 released

Aleix Conchillo Flaqué writes: > On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos wrote: > >> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]: >> > We are delighted to announce GNU Guile release 3.0.8, the latest in the >> [...] >> > The Guile 3.0.8 release mixes maintenance and optimizations

Re: (web server) serving on both ipv6 and ipv4?

"Dr. Arne Babenhauserheide" writes: > Greg Troxel writes: > >> [[PGP Signed Part:Signature made by expired key 1FDA7AE8098ED60E Gregory D. >> Troxel (low security, at work) ]] >> >> Maxime Devos writes: >> >>> Maybe the

Re: (web server) serving on both ipv6 and ipv4?

Maxime Devos writes: > Maybe the IPV6_V6ONLY (see the ipv6(7) man page) is relevant here. > Alternatively, you could run two servers in parallel: one bound to an > IPv4 address and another bound to an IPv6 address. My feeling is that IPV6_ONLY is best avoided, for portability, and because mappe

shlib major change from 3.0.3 to 3.0.4

I am packaging guile 3 in pkgsrc-wip. (It's not promoted to pkgsrc proper because I am still having some issues.) Doing the update from 3.0.3 to 3.0.4 I found this change in install files: -guile/3.0/lib/libguile-3.0.so.3.0.0-gdb.scm +guile/3.0/lib/libguile-3.0.so.1.2.0-gdb.scm and that stri

pax mprotect and guile build process

(I think I may have reported this earlier but I can't find it.) NetBSD runs with pax mprotect by default. Guile's JIT has trouble with this, due to the nature of JIT. In pkgsrc, we have: NOT_MPROTECT_SAFE+= ${GUILE_PREFIX}/bin/guile to do "paxctl +m" for guile as installed. However, du

strange shlib version change in 3.0.4

I am updating the guile 3.0 package in pkgsrc (in pkgsrc-wip for now) from 3.0.3 to 3.0.4. I noticed the following (which is really pkgsrc telling me that the new shlib is different from the old one): ERROR: ERROR: The following files

clang bug on mac, workaround

Recently someone added this line of workaround to pkgsrc: ENV.append_to_cflags "-fno-stack-check" if DevelopmentTools.clang_build_version >= 1010 (from https://github.com/Homebrew/homebrew-core/blob/master/Formula/guile.rb#L42 ) for guile 2.2.7. I don't know yet if this affects 3, bu

JIT and pax mprotect

In trying to build 3.0.2 on NetBSD 8, I get a permission denied failure in JIT, because of PaX MPROTECT. Disabling that (in the individual file, or globally) allows things to work. This is a security feature that prevents making writable mappings executable. I would expect this to run into th

Re: C calling Scheme and garbage collection

Isaac Jurado writes: > On Thu, Jun 27, 2019 at 9:52 PM Greg Troxel wrote: > >> I have been down this path before, with guile and with lua. Basically, >> if C (or non-scheme) has a pointer to a scheme object, then you need to >> hold a logical reference for it and protec

Re: C calling Scheme and garbage collection

Isaac Jurado writes: > Hello, > > I'm playing with event loop libraries implemented in C (libev, libevent, > etc... in my case libsystemd), but configuring them from Guile. > > The qsort example in the documentation [1] seems safe because the qsort C > function directly calls back, so the callbac

minor mmap protection issue

pkgsrc has the following patch for 2.2.5. At first glance it looks at least headed in the right direction, but I'd appreciate someone more familiar with the code looking and either making a corresponding fix or explaining the issue more. As I understand it, POSIX is a bit vague on this issue:

Re: Coexistence of different Guile versions

Tommi Höynälänmaa writes: > Guile (at least the Debian version) is designed so that different > versions (e.g. 2.0 and 2.2) can coexist in the same system. However, > this is not so for packages guile-xxx-dev. Consequently, many software > libraries (such as guile-gnome-platform) have to be compi

Re: moving to gitlab?

Aleix Conchillo Flaqué writes: > Any chance or interest in moving to gitlab? My apologies if this has > been discussed already. Not that I ever contribute anything directly > to Guile (2 patches in 6 years?), but it feels like it would be an > improvement in terms of communication, sending patche

Re: Officially require GNU Make to build Guile? (was Re: Bootstrap optimization)

Mark H Weaver writes: > Hmm, good question. I'm not sure, not because 2002 is too recent, but > rather because I'm not sure that GNU Make should be a requirement for > building Guile. > > Guile's README does not list GNU Make in the section of "Required > External Packages". This, along with

Re: c99 support

Andy Wingo writes: > Is there anyone who compiles Guile with a compiler that does not support > C99? If so, please give platform and compiler. Not really the question you asked, and pretty fuzzy, but an anecdote about a real situation I am aware of: In 2015--2016, there was some C code that

Re: 2.2.0 release plan

Andy Wingo writes: > However! Even though the code says 2.2.0 and the tag says 2.2.0, the > release is not until Thursday. I will not upload the tag yet. I have just barely caught up with 2.0.x in pkgsrc, and haven't gotten to testing 2.1.x yet. I wonder how many platforms 2.1.x has been tes

Re: mkostemp portability issues

Matt Wette writes: >> On Feb 20, 2017, at 6:39 PM, Greg Troxel wrote: >> + open_flags = O_APPEND|O_DIRECT|O_SHLOCK|O_EXLOCK|O_SYNC|O_CLOEXEC; > > I think you meant `&=‘ Thanks, fixed. Interestingly most of the tests passed with the wrong code. (There is an issue, but

mkostemp portability issues

Earlier I reported that 2.0.13 did not build on NetBSD. Matt Wette pointed me to a debbugs entry. The issue seems to be that mkostemp is not a POSIX-specified interface and the list of acceptable flags differs on different platforms. I have included the patch I just added to pkgsrc, which steal

2.0.13 build failure on NetBSD 7.1ish amd64

(I pretend to maintain guile in pkgsrc, a multi-os multi-os-version multi-arch packaging system, and sometimes I actually get around to it.) Due to https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8605 I'm trying again to update from 2.0.12 to 2.0.13. (I dimly remember that I tried

Re: Native code generation and gcc

Mikael Djurfeldt writes: > Are there fundamental reasons for not re-using the gcc backends for native > code generation? I'm thinking of the (im?)possibility to convert the cps to > some of the intermediate languages of gcc. Also there is llvm. If there are issues, they may be different.

Re: Parallel installation of guile-2.1.x

Jan Synáček writes: > I'd like to package guile-2.1.x so it could be used along with 2.0.13. > Using --program-suffix during the configure phase is almost what I > would like, but not quite. The problem is that there still are files > (guile.m4 and guile.info + its parts) that would conflict wit

guile-cairo status?

I just changed the guile-cairo entry in pkgsrc to guile 2.0 (we are belatedly switching). It is at 1.4,1, the last actual release. I see on savannah: http://www.nongnu.org/guile-cairo/ that there is a 1.9.91 preelease, but no actual following release. Is there a release later than 1.4.1? I

guile-lib, compiled files, packages

(I have been sort of using guile for wicked long time, I think since before 1.0, but I have been not paying attention lately and just lurking.) I am maintaining entries for guile and friends in pkgsrc, a portable packaging system that supports many operating systems, versions of those systems, an

Re: [PATCH] socket: Add AF_NETLINK support.

l...@gnu.org (Ludovic Courtès) writes: > One concern we discussed on IRC is precisely that it’s Linux-only, and > so far we’ve tried to avoid promoting Linux-only interfaces. > > An argument in favor of having it in libguile proper is that it cannot > be implemented outside since we need ‘make-so

Re: boehm-gc troubles with 2.0.11 on NetBSD/i386

A partial update: I am using 2.0.11 now. After updating to libgc 7.4.0, I have the same problem with a similar stack trace. libgc is built without threads and passes it's "gmake check". I have the same problem with libgc 7.4.0 on netbsd-5/i386 (libgc passes gmake check on this comb

Re: guile-2.0.11 build: libtool and readline problems

Ian Grant writes: > I'm at a loss. I have libtool-2.4 installed in /usr/local and I get this > error when 'make'ing after running > > ../configure --prefix=/usr/local --libdir=/usr/local/lib \ > --with-libreadline-prefix=/usr/local > > [ making lots of stuff ...] > > CCLD l

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

I am using gc-7.2e, which is what pkgsrc has, and which http://www.hboehm.info/gc/ indicates is the latest stable version. This is with gcc 4.5.3 on i386. l...@gnu.org (Ludovic Courtès) writes: > Greg, does libgc’s own ‘make check’ pass on this platform? Yes. libgc seems to have multiple t

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

Mark H Weaver writes: >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to LWP 1] >> 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 >> (gdb) bt >> #0 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1 >> #1 0xbba8696e in GC_find_l

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

Mark H Weaver writes: > As documented in our README and the output of ./configure --help, > "--without-threads" is the option you should be using. To be honest, > I'm not sure what "--disable-threads" will do, if anything. It's > possible that gnulib is somehow enabling that option to be accep

boehm-gc troubles with 2.0.10 on NetBSD/i386

I've been a guile user erratically for a long time, and maintain the entry for guile in pkgsrc. Currently that's at 1.8.8 and it works fine. There's a draft package for guile 2. boehm-gc in pkgsrc on NetBSD is built without threads, and I have --disable-threads passed to guile's configure. The

Re: 2.0.11 on OS X 10.9 / Xcode 5.1

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > >> On OS X 10.9 with Xcode 5.1, make fails unless -O0 is used; the output >> of ./configure && make during the failure is here: >> >> http://sprunge.us/PLGI >> >>

Re: About Guile crypto support

Nala Ginrut writes: > On Sat, 2013-02-09 at 16:12 +0100, Ludovic Courtès wrote: >> >> Daniel Hartwig skribis: >> An issue with the FFI is distros where .la and .so files are only >> available in the -dev package, because then ‘dynamic-link’ won’t work >> unless that -dev package is installed (

Re: Why is Guile now setting LD_LIBRARY_PATH?

Bruce Korb writes: > On 09/10/12 16:48, Bruce Korb wrote: >>> $ guile --version >>> guile (GNU Guile) 2.0.5 >>> Copyright (C) 2011 Free Software Foundation, Inc. >> >> I added a couple of debug printf's after several hours chasing down >> why my program was crashing: >> >>> in main() LD_LIBRAR

Re: Building on OpenBSD

"Taylan Ulrich B." writes: > I wanted to note that, given a working boehm-gc (the next release, 7.2d, > should work on OpenBSD 5.1, but newer OpenBSD versions, having switched > to rthreads, will break it again), and a set of build flags similar to > the following (these are tied to my personal

Re: Portability fixes for win32 cross compiling

Volker Grabsch writes: > Volker Grabsch schrieb: >> Okay, I just implemented that approach and it seems to work fine. >> There were several other issues I had to fix. Please have a look >> at the attached patches (6 in total). All of them seem to be needed >> to cross-compile guile for mingw32.

Re: Reconsideration of MinGW work

Ken Raeburn writes: > One nagging concern I've got about my Guile-Emacs project is the > seemingly narrow focus of active Guile developers as far as platforms > are concerned. I'm one of, what, two or three people testing the > development versions on Mac OS X now and then, and most of the rest

Re: request tmpfile(3) wrapping in Guile 1.9 libguile

That said, welcome back to Guile! I'm really glad to hear this - we scheme weenies are few enough in this world that we need to stick together! pgpk2RfJafl3B.pgp Description: PGP signature

Re: Deprecate vs. discourage

l...@gnu.org (Ludovic Courtès) writes: > I think things like ‘uniform-vector-read’ should be discouraged rather > than deprecated, since it matches the definition in ‘discouraged.h’: > >A discouraged feature is one that shouldn't be used in new code >since we have a better alternative now

Re: Guile 1.8.7 - Licenses

Remove or remove and re-write or ask to the copyright holder of the file inet_aton.c (guile-1.8.7/libguile/) to remove the 3º clause. UCB and the BSDs have been dropping the advertising clause. inet_ntoa sources are available from NetBSD with a 3-clause license, but it's perhaps more com

Re: TLS support on NetBSD

Thanks - I think there is actually no tls support yet. I will take a look at the autoconf issue when I have time - but I'm very busy at work this week.

Re: master with threaded gc

Thanks for all the replies. I'm not sure when I'll have a chance to look at this again, but master is building better on netbsd than it has in a long time! pgpYu8YEPA1Ki.pgp Description: PGP signature

master with threaded gc

After installing boehm-gc threaded, the build succeeds on NetBSD/amd64 5.0ish!! make check makes a lot of progress, but the hits a segfault. This may be a BSD libc problem. Making check in lib gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/lib' gmake check-recursive gmake[2]:

Re: build of master now fails much earlier

> are we really adding dependencies while we are 'frozen'??? > > checking for BDW_GC... configure: error: Package requirements (bdw-gc) > were not met: Sorry if we did not communicate clearly; the plan was definitely to merge in bdw-gc before the release, and possibly during the freez

build of master now fails much earlier

are we really adding dependencies while we are 'frozen'??? checking for BDW_GC... configure: error: Package requirements (bdw-gc) were not met: No package 'bdw-gc' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternati

Re: build failures of master on netbsd/5 amd64

The end of my build, from a few hours ago: /bin/ksh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/pkg/include -I/usr/y0/include -I/usr/pkg/include -I/usr/y0/include -pthread -Wall -Wmissing-prototypes -Werror -fvisibility=h

Re: netbsd/amd64 build getting further...

fix: diff --git a/libguile/read.c b/libguile/read.c index d91c868..5f9ce36 100644 --- a/libguile/read.c +++ b/libguile/read.c @@ -1437,7 +1437,7 @@ scm_scan_for_encoding (SCM port) /* grab the next token */ i = 0; while (pos + i - header <= SCM_ENCODING_SEARCH_SIZE -&& (isalnum(

netbsd/amd64 build getting further...

/bin/ksh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/pkg/include -I/usr/y0/include -I/usr/pkg/include -I/usr/y0/include -pthread -Wall -Wmissing-prototypes -Werror -fvisibility=hidden -g -O2 -MT libguile_la-read.lo -MD -M

build failures of master on netbsd/5 amd64

I ran 'gmake -k' to get all the warnings at once. I think there are just two groups: gmake all-recursive gmake[1]: Entering directory `/home/gdt/BUILD-GUILE-master/guile' gmake[2]: Entering directory `/home/gdt/BUILD-GUILE-master/guile/libguile' gmake all-am gmake[3]: Entering directory `/hom

Re: apparenty SCM_I_CHAR is fixed, but:

l...@gnu.org (Ludovic Courtès) writes: > Mike Gran writes: > >> On Wed, 2009-08-19 at 09:56 -0400, Greg Troxel wrote: >>> From my autobuild on master >>> >>> vm-i-scheme.c:437: warning: comparison is always true due to limited range >>> of d

apparenty SCM_I_CHAR is fixed, but:

From my autobuild on master cc1: warnings being treated as errors In file included from vm-engine.c:133, from vm.c:322: vm-i-scheme.c: In function 'vm_regular_engine': vm-i-scheme.c:437: warning: comparison is always true due to limited range of data type vm-i-scheme.c:437: warn

Re: `SCM_MAKE_CHAR ()' signedness issue

I think the problem is that the routine in question is fundamentally written to assume a signed input. Perhaps there should be an unsigned version that takes unsigned chars, and perhaps guile should explicit declare characters as one or the other. Or perhaps just always cast to unsigned char - i

Re: i guess we're frozen & stuff

l...@gnu.org (Ludovic Courtès) writes: >> My conclusion so far is that "(void *)0" is a legal value for NULL > > Whether "legal" or not, under-parenthesized expression-like macros are > likely to cause troubles one day or another. > > Thanks for your work with the upstream people! I now have a p

Re: i guess we're frozen & stuff

http://mail-index.netbsd.org/tech-userlevel/2009/08/thread1.html#002545 http://savannah.gnu.org/support/?106973 My conclusion so far is that "(void *)0" is a legal value for NULL (even given as an example in POSIX 2008 glossary), and that just because an expression E evaluates to an integer cons

Re: i guess we're frozen & stuff

l...@gnu.org (Ludovic Courtès) writes: > Greg Troxel writes: > >> #define NULL (void *)0 > > This is under-parenthesized! > > Two actions to be taken: > > 1. Report a bug to your favorite libc maintainers. ;-) I think that's a legal value for NULL

Re: i18n issues on NetBSD

scheme@(guile-user)> (setlocale LC_ALL "does-not-exist") "C" list gdt 8 ~ > cat l.c #include #include #include #include #include int main (int argc, char *argv[]) { char *s; s = setlocale (LC_ALL, "C"); assert (s != NULL); printf ("DAY_1: %s\n", nl_langinfo (DAY_1)); s =

Re: i guess we're frozen & stuff

l...@gnu.org (Ludovic Courtès) writes: > Ken Raeburn writes: > >> However, they're testing for a POSIX 2008 requirement that C99 and >> POSIX 2004 implementations need not meet, namely that NULL be of type >> "void *" instead of any null pointer constant (e.g., "0"). I think >> requiring POSIX

Re: i guess we're frozen & stuff

The essential bit is: #define NULL (void *)0 pgpuZFJtB2uAZ.pgp Description: PGP signature

Re: i guess we're frozen & stuff

requested tests follow list gdt 52 ~/BUILD-GUILE-master/guile > ./meta/guile ;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-autocompile argument to disable. ;;; compiling /home/gdt/BUILD-GUILE-master/guile/guile-readline/ice-9/readline.scm ;;; compiled

Re: i guess we're frozen & stuff

Does libunistring's "make check" pass on this platform? should have tried that. testlocale.c fails on line 38 with: test-locale.c:38: error: expected ')' before numeric constant expanding that with cpp gets me the rather stunning: extern int (* verify_function__ (void)) [(!!sizeof (struct

unsigned char confusion

In srfi-13.c line 25222, SCM_MAKE_CHAR is called with an argument that is an unsigned char. This leads to: cc1: warnings being treated as errors srfi-13.c: In function 'string_titlecase_x': srfi-13.c:2522: warning: comparison is always false due to limited range of data type srfi-13.c:2522: war

Re: i guess we're frozen & stuff

guile master fails to build on NetBSD because it passes characters to tolower, which is specified to take an int. It's really a macro, and this is a messy situation. The language weenies I've talked to about this think that in this case it's the program that passes a char that's wrong. Hence th

Re: i guess we're frozen & stuff

I built libunistring and tried to build master. Some tests failed, and also the build failed due to warnings (post to follow). I think all the failed tests are locale related. "gmake check" output on NetBSD/amd64 5.0 with libunistring 0.9.1: Making check in lib gmake[1]: Entering directory `/h

Re: i guess we're frozen & stuff

Today's the 10th, we release on the 15th, ergo we're frozen. What does this mean? Well I think the dilly is that we shouldn't be pushing to master, except to fix things that don't work at all, and to update documentation, NEWS, etc. What if you don't have push access? Well give Guile a

Re: Guile 2.x and `pkg-config'

l...@gnu.org (Ludovic Courtès) writes: > A recent thread on `guile-user' [0] raises an important concern: what > should we do with `guile-1.8.pc' when 2.x is out? > > How about shipping `guile-1.8.pc' for compatibility, along with > `guile.pc' (which would then become the Right One), both with >

Re: master build issue

Neil Jerram writes: > configure:52553: ccache gcc -o conftest -g -O2 conftest.c -L/usr/local/lib > -lunistring -R/usr/local/lib -lgmp -lcrypt -lm -lltdl >&5 > gcc: unrecognized option '-R/usr/local/lib' > > My GCC is version 4.3.2, so pretty recent. > > Ludo, Andy, I'm wondering why this isn

Re: new dependency?

writes: > Neil Jerram wrote: >> Greg Troxel writes: >> >> > my autobuild choked with: >> > >> > configure: error: GNU libunistring is required, please install it. >> > >> > and I don't recall seeing any discussion

1.8 branch test failure

Git tree... release_1-8-6-53-g66f3b6c GCC version... gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb1 20080202) Differences: End differnces. [snip] FAIL: popen.test: open-input-pipe: open-input-pipe process gets (current-input-port) as stdin [snip] Totals for this test run: passes:

new dependency?

my autobuild choked with: configure: error: GNU libunistring is required, please install it. and I don't recall seeing any discussion about this. pgpTeIae3j2Eu.pgp Description: PGP signature

git server broken?

My autobuild failed, and on checking: list gdt 12 ~/BUILD-GUILE-1.8/guile > git pull git.sv.gnu.org[0: 199.232.41.69]: errno=Connection refused fatal: unable to connect a socket (Connection refused) pgpMCBsYyRpJV.pgp Description: PGP signature

Re: 1.8 autobuild fails

Yes, it's new. Git tree... release_1-8-6-44-ge9c9fd3 This is my 1.8 branch autobuild: http://autobuild.josefsson.org/guile/log-200905090633244263000.txt And yes, including sys/types.h fixes this. At least on BSD, one generally needs to include sys/types.h before random header files in mac

1.8 autobuild fails

This fails in test-round.c. It's likely like "foo.h needs sys/types.h" but I haven't looked yet - just wanted to point it out. gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/pkg/include -I../../test-suite/standalone -I../.. -I../.. -I/usr/pkg/include -pthread -g -O2 -Wall -Wmissing-prototypes -Wer

Re: buidl failure on master

Andy Wingo writes: > I think I've fixed this -- at least it works now on OSX 10.5. Can you > give it another roll? Builds fine and passes gmake check - thanks. >> (Plus, it probably won't work with crossbuilding, but even if that's >> fixed native builds still need to use the not-yet-installed

buidl failure on master

My autobuild (NetBSD/amd64) for master wedged due to some git lossage (local changes interfering with git pull). I recovered that and it's now failing: cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc deprecation.doc deprecated.doc discourage

Re: master build failure on netbsd

Andy Wingo writes: > Hi, > > On Thu 02 Apr 2009 05:05, Greg Troxel writes: > >> debug.c: In function 'init_stack_limit': >> debug.c:532: warning: comparison is always false due to limited range of >> data type >> debug.c:535: warning: comparison i

master build failure on netbsd

my autobuild failed this morning: /bin/ksh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.. -I.. -I../lib -I../lib -I/usr/pkg/include -I/usr/pkg/include -pthread -Wall -Wmissing-prototypes -Werror -g -O2 -MT libguile_la-debug.lo -MD -MP -MF .deps/libguile_la-debug.Tpo -c -o libg

Re: request review: branch "wingo"

Speaking of which, should we mark `guile-config' as deprecated in favor of `pkg-config' (in 1.9)? I think so. An advantage of pkg-config, beyond the not-rolling-your-own, is that pkgsrc has generic fixup support for -R, and a separate fix for guile-config, and it would be nice to get rid of

Re: stack calibration

Neil Jerram writes: > The primary purpose of stack-limit-calibration.scm is to allow "make > check" to succeed on those platforms, That's fine. > and it now makes sense to > generalize that to any other guile-using operations that we run during > the build - such as compiling. Not quite; the

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

l...@gnu.org (Ludovic Courtès) writes: > Hi Greg, > > Greg Troxel writes: > >> I don't think that's true at all. It could be that for running Linux on >> arm pdas that's what most people do, but for the far more general case >> there is normal

Re: Guile 1.8 success on `i386-apple-darwin9.6.0'

l...@gnu.org (Ludovic Courtès) writes: > Hmm, right. OTOH, my impression was that tools like Scratchbox had > taken the world over, meaning that cross-compilation usually takes place > as "native" compilation in an emulated target environment. I don't think that's true at all. It could be that

Re: vm merged to master

My autobuild failed this morning (1000Z) during the build phase: http://autobuild.josefsson.org/guile/log-200903140604763094000.txt It had previously been failing in make check: http://autobuild.josefsson.org/guile/log-200903130603258959000.txt pgpcq1xhCqM3J.pgp Description: PGP signatur

Re: Locks and threads

Does that sound sensible; have I missed anything? Also run tests on other than Linux, with as many different OS threading implementations as possible. For all systems, set the threading libraries to the most restrictive settings, specifically aborting on any behavior the standard says is undef

Re: guile-lib licensing (input requested)

l...@gnu.org (Ludovic Courtès) writes: > Hi! > > Andy Wingo writes: > >> We should probably have some kind of policy regarding licenses. Here are >> some options that I can think of: > > I'd say leave PD code PD, and move GPLv2+ files to GPLv3+, with clear > license headers. (My understanding i

Re: pthread crash on master

[2. application/octet-stream; 0001-Don-t-try-to-unlock-already-unlocked-heap-mutex.patch]... With that patch, make check runs successfully. log at http://autobuild.josefsson.org/guile/log-200901161104820417000.txt thanks for the fix. pgptHd2B37bCL.pgp Description: PGP signature

Re: git head fails to build

"Neil Jerram" writes: > 2009/1/15 Greg Troxel : >>> 2009/1/15 Greg Troxel : >>>> AB_INIT is not present in master, just in 1.8 (I think - I am still a >>>> git newbie). >>> >>> It's hidden somewhere inside gl_INIT or gl_EA

Re: git head fails to build

"Neil Jerram" writes: > 2009/1/15 Greg Troxel : >> AB_INIT is not present in master, just in 1.8 (I think - I am still a >> git newbie). > > It's hidden somewhere inside gl_INIT or gl_EARLY. hmm, that seems wrong for a library component t

Re: git head fails to build

Thanks for all the fixes - I can build both now. Remaining issues: AB_INIT is not present in master, just in 1.8 (I think - I am still a git newbie). INSTALL is checked in, but gets overwritten by autoreconf. It seems like since this is a generated file it should not be checked in.

pthread crash on master

(Thansk - now I can build master and branch-release_18.) 1.8 passes make check. master fails with a core dump due to mutex abuse in the socket test: http://autobuild.josefsson.org/guile/log-200901151131125464000.txt here is a backtrace of the thread that crashed (gdb) i thr 4 process 6967

Re: git head fails to build

(has anyone else built head of git?) Now I get: list gdt 3 ~/BUILD-GUILE-1.9.0 > ./build-guile.sh remote: Counting objects: 8, done. remote: Compressing objects: 100% (5/5), done. remote: Total 5 (delta 3), reused 0 (delta 0) Unpacking objects: 100% (5/5), done. From git://git.sv.gnu.org/guile

Re: git head fails to build

Here's the build-guile script, which I got from someone on this list build-guile.sh Description: Bourne shell script pgpgoc2V8j3RW.pgp Description: PGP signature

  1   2   >