Re: guile-1.5.6: some build comments

[Neil Jerram <neil@ossau.uklinux.net>]

>>>>> "Nelson" == Nelson H F Beebe <beebe@math.utah.edu> writes:

    Nelson> I've made installation attempts for guile-1.5.6 on 13+
    Nelson> different UNIX platforms, with a few successes (GNU/Linux
    Nelson> systems), and several failures, either of the build, or of
    Nelson> parts of the test suite.  A brief summary is given below;
    Nelson> details, including full build logs, are available on
    Nelson> request.  Builds were done with the usual recipe

    Nelson> 	./configure && make all check install

Thanks enormously for such extensive testing!

    Nelson> ------------------------------------------------------------------------
    Nelson> Apple Darwin (== MacOS X):
    Nelson> 	gcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -g -O2 -Wall -Wmissing-prototypes -c gc_os_dep.c -Wp,-MD,.deps/gc_os_dep.TPlo  -fno-common -DPIC -o .libs/gc_os_dep.lo
    Nelson> 	gc_os_dep.c:356: illegal external declaration, found `--'
    Nelson> 	gc_os_dep.c:356: undefined type, found `unknown'
    Nelson> 	gc_os_dep.c:356: illegal external declaration, missing `;' after `machine'
    Nelson> 	cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode
    Nelson> 	gc_os_dep.c:356: parse error before `--'
    Nelson> 	make[2]: Leaving directory `/local/build/guile-1.5.6/libguile'

This is a deliberate error.  It indicates that no one has yet worked
out how to build the Boehm GC on MacOS X, or at least, that the
solution is not recorded in Guile's copy of this file.

Someone needs to check the latest status on this.  Now that MacOS X
has been out for a while, my guess is that the main Boehm GC sources
will now cover this case.

    Nelson> ------------------------------------------------------------------------
    Nelson> Compaq/DEC Alpha OSF/1 4.0:
    Nelson> 	cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc gc.doc goops.doc gsubr.doc guardians.doc hash.doc hashtab.doc hooks.doc init.doc ioext.doc iselect.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc strop.doc strorder.doc strports.doc struct.doc symbols.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc symbols-deprecated.doc regex-posix.doc ramap.doc unif.doc filesys.doc posix.doc net_db.doc socket.doc | GUILE="/export/home/0023/build-alpha-osf1/guile-1.5.6/pre!
-i!
nst-guile" .!
    Nelson> ./scripts/snarf-check-and-output-texi > guile.texi || { rm guile.texi; false; }
    Nelson> 	ERROR: Wrong number of arguments to #<procedure snarf-check-and-output-texi ()>
    Nelson> 	make[2]: *** [guile.texi] Error 1
    Nelson> 	make[2]: Leaving directory `/export/home/0023/build-alpha-osf1/guile-1.5.6/libguile'

Fascinating.  My guess is that, on this OS, the shell processes "$@"
so that it ends up as a single, empty string argument, even when no
arguments were actually supplied.  Could you run your /bin/sh and try
the following lines?

$ set -
$ echo $#
$ set - "$@"
$ echo $#

snarf-check-and-output-texi has since changed so that it accepts any
number of args, but "$@" is part of our standard boilerplate for Guile
scripts, so if it doesn't work, we have an issue ...

    Nelson> ------------------------------------------------------------------------
    Nelson> Compaq Alpha OSF/1 5.0:
    Nelson> [No gcc release can be built on this platform, so the autoconf
    Nelson> config.site file sets

    Nelson>         CC='cc -ieee'
    Nelson>         CXX='cxx -x cxx -ieee'

    Nelson> to force use of native compilers with conformance to the nonstop
    Nelson> computing model of IEEE 754 arithmetic.]

    Nelson> 	cc -ieee -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -I../libltdl -g -c -MD gc_os_dep.c  -DPIC -o .libs/gc_os_dep.lo
    Nelson> 	cc: Error: gc_os_dep.c, line 1851: In this statement, "result" and "((ptr_t)((word)(&__start)&~(getpagesize(...)-1)))" cannot be compared with a relational operator. (norelational)
    Nelson> 			    if (result > HEURISTIC2_LIMIT
    Nelson> 	------------------------^
    Nelson> 	make[2]: *** [gc_os_dep.lo] Error 1

Compiler seems to be complaining about comparing a void * with a char
*.  Does changing the line to

		    if ((ptr_t)result > HEURISTIC2_LIMIT

help?

    Nelson> ------------------------------------------------------------------------
    Nelson> IBM RS/6000 AIX 4.3:
    Nelson> 	./guile_filter_doc_snarfage --filter-snarfage) > socket.doc || { rm socket.doc; false; }
    Nelson> 	cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc gc.doc goops.doc gsubr.doc guardians.doc hash.doc hashtab.doc hooks.doc init.doc ioext.doc iselect.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc strop.doc strorder.doc strports.doc struct.doc symbols.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc symbols-deprecated.doc regex-posix.doc ramap.doc unif.doc filesys.doc posix.doc net_db.doc socket.doc | GUILE="/local/build/guile-1.5.6/pre-inst-guile" ../script!
s/!
snarf-check-!
    Nelson> and-output-texi > guile.texi || { rm guile.texi; false; }
    Nelson> 	Could not load program guile
    Nelson> 	Member libguile.so.14 not found or file not an archive
    Nelson> 	Member libguile.so.14 not found or file not an archive
    Nelson> 	Could not load library libguile.a[libguile.so.14]
    Nelson> 	Error was: No such file or directory

Scary libtool issue.  If you ignore this problem (by using `make -k'),
does the installed guile work correctly?

In other words, is this a case of `libtool doesn't work at all' on
AIX, or is it only a pre-installation problem?

    Nelson> ------------------------------------------------------------------------
    Nelson> Several GNU/Linux systems:

    Nelson> 	Testing /local/build/guile-1.5.6/pre-inst-guile ...
    Nelson> 	with GUILE_LOAD_PATH=/local/build/guile-1.5.6/test-suite
    Nelson> 	FAIL: syncase.test: (ice-9 syncase) loads

    Nelson> The tests are largely successful:

    Nelson> 	Totals for this test run:
    Nelson> 	passes:                 2115
    Nelson> 	failures:               1
    Nelson> 	unexpected passes:      0
    Nelson> 	expected failures:      17
    Nelson> 	unresolved test cases:  0
    Nelson> 	untested test cases:    0
    Nelson> 	unsupported test cases: 9
    Nelson> 	errors:                 0

    Nelson> 	FAIL: check-guile

I believe this has since been fixed in CVS by the following change:

2002-03-12  Rob Browning  <rlb@defaultvalue.org>

	* syncase.scm (gensym): fix failure on non-threaded systems.

    Nelson> ------------------------------------------------------------------------
    Nelson> SGI IRIX 6.5:
    Nelson> Build like this:
    Nelson> 	env CC="c89 -mips3 -O2" CXX=CC -mips3 -O2 \
    Nelson> 		LDFLAGS=" -rpath /usr/local/lib -L/usr/local/lib" \
    Nelson> 			./configure && make all check

    Nelson> 	./guile_filter_doc_snarfage --filter-snarfage) > socket.doc || { rm socket.doc; false; }
    Nelson> 	cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc continuations.doc debug.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc gc.doc goops.doc gsubr.doc guardians.doc hash.doc hashtab.doc hooks.doc init.doc ioext.doc iselect.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc strop.doc strorder.doc strports.doc struct.doc symbols.doc throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc symbols-deprecated.doc regex-posix.doc ramap.doc unif.doc filesys.doc posix.doc net_db.doc socket.doc | GUILE="/local/build/guile-1.5.6/pre-inst-guile" ../script!
s/!
snarf-check-!
    Nelson> and-output-texi > guile.texi || { rm guile.texi; false; }
    Nelson> 	ERROR: Stack overflow
    Nelson> 	make[2]: *** [guile.texi] Error 1
    Nelson> 	make[2]: Leaving directory `/export/home/0061/build-indigo-irix6/guile-1.5.6/libguile'

Curious.  Could you try adding these two lines at line 35 of
scripts/snarf-check-and-output-texi, and send us the output (which
will hopefully include a backtrace):

(debug-enable 'debug)
(debug-enable 'backtrace)

    Nelson> ------------------------------------------------------------------------
    Nelson> Sun Solaris 2.7 and 2.8:
    Nelson> 	Testing /export/staff/computing/beebe/i386/build/guile-1.5.6/pre-inst-guile ...
    Nelson> 	with GUILE_LOAD_PATH=/export/staff/computing/beebe/i386/build/guile-1.5.6/test-suite
    Nelson> 	ERROR: regexp.test: regexp-substitute/global: ("" "" ""): port is string port - arguments: ((regular-expression-syntax "make-regexp" "empty (sub)expression" #f #f))
    Nelson> 	ERROR: regexp.test: regexp-substitute/global: ("" "" ""): port is #f - arguments: ((regular-expression-syntax "make-regexp" "empty (sub)expression" #f #f))

These errors are being passed through from the Solaris libc's
implementation of regcomp and regerror - apparently, its regcomp
doesn't handle empty expressions.  Perhaps best just documented and
lived with, although we could probably code a workaround on the Scheme
level if we wanted to.

    Nelson> 	ERROR: srfi-19.test: SRFI date/time library: #<procedure time-utc->date (time . tz-offset)> respects local DST if no TZ-OFFSET given - arguments: ((system-error "putenv" "~A" ("No such file or directory") (2)))

How is putenv's return code documented on Solaris?  Looks like putenv
is returning <0, which Guile, perhaps wrongly, interprets as an error.

    Nelson> 	FAIL: syncase.test: (ice-9 syncase) loads

As for GNU/Linux systems above.

    Nelson> ------------------------------------------------------------------------
    Nelson> Sun Solaris 2.8:
    Nelson> 	gcc -shared  alist.lo arbiters.lo async.lo backtrace.lo boolean.lo chars.lo continuations.lo debug.lo deprecation.lo dynl.lo dynwind.lo environments.lo eq.lo error.lo eval.lo evalext.lo extensions.lo feature.lo fluids.lo fports.lo gc.lo gc_os_dep.lo gdbint.lo gh_data.lo gh_eval.lo gh_funcs.lo gh_init.lo gh_io.lo gh_list.lo gh_predicates.lo goops.lo gsubr.lo guardians.lo hash.lo hashtab.lo hooks.lo init.lo ioext.lo iselect.lo keywords.lo lang.lo list.lo load.lo macros.lo mallocs.lo modules.lo numbers.lo objects.lo objprop.lo options.lo pairs.lo ports.lo print.lo procprop.lo procs.lo properties.lo random.lo rdelim.lo read.lo root.lo rw.lo scmsigs.lo script.lo simpos.lo smob.lo sort.lo srcprop.lo stackchk.lo stacks.lo stime.lo strings.lo strop.lo strorder.lo strports.lo struct.lo symbols.lo throw.lo values.lo variable.lo vectors.lo version.lo vports.lo weaks.lo symbols-deprecated.lo regex-posix.lo ramap.lo unif.lo filesys.lo posix.lo net_db.lo socket.lo inet_aton.l!
o !
 -Wl,--rpath!
    Nelson>  -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib  -L/usr/local/lib /usr/local/lib/libltdl.so -lcrypt -lsocket -lnsl -lm -lc  -Wl,-rpath -Wl,-soname -Wl,libguile.so.14 -o .libs/libguile.so.14.1.0
    Nelson> 	/usr/local/sparc-sun-solaris2.7/bin/ld: cannot open libguile.so.14: No such file or directory
    Nelson> 	collect2: ld returned 1 exit status

This is odd for two reasons:

- you say 2.8, but the path to ld in the error message says 2.7

- If Guile fails to link, as shown here, how did you get as far as the
  `make check' errors reported above?

Can you throw any extra light on these?


Many thanks again!  Hopefully we can nail all of these before 1.5.7.

        Neil


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