Hi Bruno,

Bruno Haible <bruno@clisp.org> skribis:

>> >     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.

I know, I know.  I really view README as a hint, in the hope that the
user will understand that /path/to/libgc/lib/pkgconfig will have to be
replaced by the correct file name.  I don’t think another convention,
such as writing $LIBFFI_LIBDIR, really helps.

>> > 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.

[...]

> 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.

The problem we could run into, by not using libffi’s and BDW-GC’s
recommended methods, is that we could miss CFLAGS, CPPFLAGS, or LDFLAGS
that appear in their .pc files.

Thus, it seems more robust to configure these packages the way they are
meant to be configured, rather than do our own guesswork.

WDYT?

Perhaps the pkg-config discussion should actually be moved to bug-gnulib
or bug-standards, because it’s beyond Guile’s scope.

> 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.

Hmm, OK, noted!

>> > 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.

Yes, sure.  It turns out that i18n.{c,scm} in Guile predate the
‘langinfo’ module in Gnulib, and Guile’s needs may be different than
those of other packages.

Actually, I have a stash here to do that (see below), but I can’t
remember why I didn’t apply it.  I’ll try again and report back.

>> > 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?

This is being discussed elsewhere:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10336
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9900#35

Thanks,
Ludo’.