Hi Ludo, > Thanks for the quick and detailed report!
Another set of platforms is being tested right now. -------------------------------------------------- About configuration of the dependencies: > > How about changing that section to mention > > 1) that pkg-config ought to be installed before libffi and libgc? > > 2) that usually setting PKG_CONFIG_PATH to include > > $BDW_LIBDIR/pkgconfig:$LIBFFI_LIBDIR/pkgconfig:/usr/lib/pkgconfig > > will work, > > 3) the BDW_GC_CFLAGS, BDW_GC_LIBS, LIBFFI_CFLAGS, LIBFFI_LIBS > > approach as a last resort. > > I’ve done something along these lines: > > > http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=ad17b1551241a0fbaa9f9557016cbe440cc6338b Hmm, two comments about your advice PKG_CONFIG_PATH=/path/to/libgc/lib/pkgconfig:/path/to/libffi/lib/pkgconfig - When the packages are installed on a bi-arch system, in $prefix/lib64/ (or, on Solaris, $prefix/lib/64/), then the pkgconfig dir is a subdir of that directory. More precisely, if the package was installed with --libdir=$LIBFFI_LIBDIR, then the dir to use is $LIBFFI_LIBDIR/pkgconfig. - If the user sets this variable and then forgets about it, and it does not contain /usr/lib/pkgconfig or /usr/lib64/pkgconfig, then AFAIU other packages installed in /usr/lib[64] will no longer be found. > > 2) On Linux/glibc/PowerPC, MacOS X 10.5, Cygwin, I happen not to have > > pkg-config installed. But I have installed all the other packages! > > The configuration fails: > > [...] > > > Isn't this a *gratuitous* build dependency? > > Isn’t this a gratuitous troll? ;-) Given the size of the thread about this topic in gnu-prog-discuss, it is not gratuitous to talk about it. > Seriously, I understand your frustration. Yet, we use upstream’s method > to check for package availability, whether we like it or not. You can do better than that. > > I won't install pkg-config. If you want me to test guile on Linux/PowerPC, > > MacOS X 10.5, Cygwin, and mingw, provide an alternative. > > One can define $BDW_GC_LIB, etc. as described in the manual. Would that > work for you? This is even more work, no thanks. I mean, after I installed the prerequisite packages with the same --prefix, guile found libiconv, libintl, libunistring, libgmp all automatically, without any further ado - because you are using the gnulib module 'havelib'. For packages as simple as libffi and gc, these macros will work as well. Can't you just change PKG_CHECK_MODULES(LIBFFI, libffi) to AC_LIB_HAVE_LINKFLAGS([ffi], [], [#include <ffi.h> #include <stdlib.h>], [ffi_call (NULL, NULL, NULL, NULL);]) if test "$HAVE_LIBFFI" = yes; then LIBFFI_CFLAGS= # CPPFLAGS already augmented LIBFFI_LIBS="$LTLIBFFI" # since linking is done with libtool else PKG_CHECK_MODULES(LIBFFI, libffi) fi and similarly for libgc. If this gets too complicated, I can extend the gnulib 'havelib' module to also invoke pkg-config when the search in the various directories failed. -------------------------------------------------- > > 4) On Solaris 11 (both x86 and x86_64), > > Do you mean OpenIndiana or something? No, I meant Oracle Solaris 11, released on 2011-11-09. Cf. http://en.wikipedia.org/wiki/Solaris_(operating_system) http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html But I warn you: with this OS, before you have a usable system, you have to learn how to use their package manager. Otherwise, no gcc, no development tools. -------------------------------------------------- > > This could be easily fixed by including the gnulib module 'nl_langinfo'. See > > http://www.gnu.org/software/gnulib/manual/html_node/nl_005flanginfo.html > > I considered using it some time ago but decided not to, as the comment > in i18n.c says: > > Note: We don't use Gnulib's `nl_langinfo' module because it's currently not > as complete as the compatibility hacks in `i18n.scm'. */ If you are not satisfied with the contents of a particular gnulib module, please by all means say so on the bug-gnulib list. I beg you. Then the enhancements will not only profit guile but also other packages. -------------------------------------------------- > > 9) Test failure on Linux/glibc/i386 (32-bit build on a x86_64 machine): > > > > FAIL: gc.test: gc: Lexical vars are collectable > > This is a known “problem”, and harmless. Then, why not change the test so that it only prints a warning message, and always succeeds? -------------------------------------------------- Bruno
