building versus just using native guile?

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

Re: 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: building versus just using native guile?

[Robert P. J. Day]

On Wed, 18 Nov 2009, Philip Balister wrote:

> 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; }

  i'm effectively on F12 (rawhide updated F11), about to re-install
fresh with F12.  not that long ago, adrian alonso(?) mentioned that,
when his build of guile-native failed, he *manually* ran that failing
step, substituting a reference to the already-installed guile on his
system, and that seemed to work.

  and when i pull open the guile 1.8.7 tarball (i was testing to see
if a newer version would help), down in the libguile directory, in
Makefile.am, there's this snippet that clearly represents that command
that's failing:

=====

alldotdocfiles    = $(DOT_DOC_FILES) $(EXTRA_DOT_DOC_FILES)
snarf2checkedtexi = GUILE="$(GUILE_FOR_BUILD)" $(top_srcdir)/scripts/snarf-check-and-output-texi
dotdoc2texi       = cat $(alldotdocfiles) | $(snarf2checkedtexi)

=====

  you can see how those Makefile variables are set up to construct
that massive "cat" command that eventually fails.  and how the GUILE
variable is being set to the constructed version (pre-inst-guile)
rather than to the native version, even after i set the
GUILE_FOR_BUILD env variable.  so all i can deduce is that that env
var isn't percolating down to the libguile build step.

  so i'm still confused.  and i'm guessing that my f12-ishness on this
system is what's causing the difference in our builds.

rday
--


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

            Linux Consulting, Training and Kernel Pedantry.

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

Re: building versus just using native guile?

[Robert P. J. Day]

On Wed, 18 Nov 2009, Philip Balister wrote:

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

  the prognosis:

  https://bugzilla.redhat.com/show_bug.cgi?id=538707

see comment 3.

rday
--

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

            Linux Consulting, Training and Kernel Pedantry.

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