[oe] building versus just using native guile?

[Philip Balister]

Can you remind me what distro you are using on your build machine? 
Normally, I seem to share your pain, but beagle-demo-image is building 
for me at the moment. (I'm basically wiping tmp and starting over as 
fast as i can atm)

I am building on F11.

Philip

On 11/18/2009 09:40 AM, Robert P. J. Day wrote:
>
>    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
> ========================================================================
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>