GNU bug report logs - #10520
[platform-testers] Guile 2.0.4 release imminent

Previous Next

Full log

View this message in rfc822 format

From: Bruno Haible <bruno <at> clisp.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Andy Wingo <wingo <at> pobox.com>, 10520 <at> debbugs.gnu.org
Subject: bug#10520: [platform-testers] Guile 2.0.4 release imminent
Date: Tue, 17 Jan 2012 01:22:52 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.