guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: i guess we're frozen & stuff


From: Ken Raeburn
Subject: Re: i guess we're frozen & stuff
Date: Tue, 11 Aug 2009 09:59:57 -0400

On Aug 11, 2009, at 07:34, Greg Troxel wrote:
Have there been recent reports of success of 1.9.x on platforms other
than GNU/Linux?  Guile has been quite portable in the past and it's
surely still very close if not there, and it would be a shame if 2.0 had
issues.  I realize this is hard for people to test if they don't have
the platform, but it would be really good to have testing on at least
one normal BSD and also Darwin.


The Mac build off of "master" fails for me currently in srfi-13.c, with the comparison-always-false warning Greg discussed. I hacked around that, but then guile-readline doesn't build:

Making all in guile-readline
../libguile/guile-snarf -o readline.x ../../guile-readline/readline.c - DHAVE_CONFIG_H -I. -I.. -I../../guile-readline/.. -I../../guile- readline/lib -I./lib -g -O2
In file included from ../../guile-readline/readline.c:29:
../../guile-readline/../libguile.h:25:17: error: gmp.h: No such file or directory
In file included from ../../guile-readline/../libguile.h:95,
                 from ../../guile-readline/readline.c:29:
../../guile-readline/../libguile/strings.h:26:21: error: uniconv.h: No such file or directory

Neither the path specified for libgmp nor the path specified for libunistring at configure time is included here.

I don't think any of this is Mac-specific; I'm surprised that it works on GNU/Linux systems. Perhaps I'm building it in ways that are unusual for the other developers (build dir != src dir, libgmp and guile-1.8 installed in the same place, libgmp and libunistring installed in different nonstandard directories)?

If I use CPPFLAGS=... and LDFLAGS=... instead of --with-libfoo-prefix configure options to specify paths to find libgmp and libunistring, the tests still pick old, installed Guile headers (which this time I've poisoned to highlight the problem) from those locations instead of the in-tree versions:

Making all in test-suite
Making all in standalone
../../libguile/guile-snarf -o test-asmobs-lib.x ../../../test-suite/ standalone/test-asmobs-lib.c -DHAVE_CONFIG_H -I. -I../../../test-suite/ standalone -I../.. -I/opt/local/include -I/Users/raeburn/dev/guile/ libunistring-0.9.1/I/include -g -O2 -I../../.. -I../../../lib -I../../ lib -I../..
In file included from /opt/local/include/libguile.h:30,
from ../../../test-suite/standalone/test-asmobs- lib.c:23:
/opt/local/include/libguile/__scm.h:3:2: error: #error Poison!

I might be building Guile as part of a larger package (*cough*Emacs*cough*) that wants to include stuff from the same system directories (e.g., for MacPorts, pkgsrc, whatever) where an old version of Guile is installed, and thus Guile gets passed CPPFLAGS/ LDFLAGS settings that add that old version to the search paths. So I think the CPPFLAGS/LDFLAGS version needs to be made to work, as well as the --with-libfoo-prefix version.

With the attached patch, I can get guile to build with CPPFLAGS= and LDFLAGS= ... someone more familiar than I am with automake will have to fix the guile-readline stuff. Even with my patch, it fails its tests:

make  check-TESTS
Testing /Users/raeburn/dev/guile/git/guile/b3/meta/guile ...
with GUILE_LOAD_PATH=/Users/raeburn/dev/guile/git/guile/test-suite
ERROR: In procedure make_objcode_by_mmap:
ERROR: bad header on object file: "GOOF-0.6-LE-4---"
FAIL: check-guile

Still looking into that....

Ken

Attachment: guile-master.diff
Description: Binary data



reply via email to

[Prev in Thread] Current Thread [Next in Thread]