[oe] building versus just using native guile?

[Robert P. J. Day]

  i'm hoping there's a simple OE solution to this.  i'm still fighting
trying to bitbake guile-native, and here's the tail end of log file
that shows the problem:

cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc
chars.doc continuations.doc debug.doc deprecation.doc deprecated.doc
discouraged.doc dynl.doc dynwind.doc environments.doc eq.doc error.doc
eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc
futures.doc gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc
gc-malloc.doc gc-card.doc guardians.doc hash.doc hashtab.doc hooks.doc
i18n.doc init.doc ioext.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 srfi-4.doc srfi-13.doc
srfi-14.doc strorder.doc strports.doc struct.doc symbols.doc
threads.doc throw.doc values.doc variable.doc vectors.doc version.doc
vports.doc weaks.doc ramap.doc unif.doc dynl.doc filesys.doc posix.doc
net_db.doc socket.doc regex-posix.doc |
GUILE="/home/rpjday/oe/angstrom-dev/work/x86_64-linux/guile-native-1.8.7-r0/guile-1.8.7/pre-inst-guile"
../scripts/snarf-check-and-output-texi          >
guile-procedures.texi || { rm guile-procedures.texi; false; }


  long story short, the fact that it's the pre-installation version of
guile that's being used there is what's killing the build.  if my
already-installed native guile were used, apparently there would be no
problem.  so ... is there an OE setting that just says, no, use the
guile that's already installed.

  a bit more detail -- i downloaded the 1.8.7 tarball and found the
following in the top-level README:

"The `GUILE_FOR_BUILD=...' setting is needed because some later steps
of the build process use Guile itself.  In the non-cross-compiling
case this is the version of Guile that has just been built.  When
cross-compiling, you have to set GUILE_FOR_BUILD to tell the build
where it can find a native version of Guile, to use for these steps."

  i have, in fact, tried that, but it doesn't make a difference.  i'm
about to follow the logic down to see how one affects that GUILE
variable at that stage.  but is there a simpler way to just point OE
at the native guile for this step?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================