From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: openembedded-devel@lists.openembedded.org
Subject: Re: building versus just using native guile?
Date: Wed, 18 Nov 2009 10:22:48 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.00.0911181018010.22422@localhost> (raw)
In-Reply-To: <4B040BB5.20308@balister.org>
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
========================================================================
next prev parent reply other threads:[~2009-11-18 15:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 14:40 building versus just using native guile? Robert P. J. Day
2009-11-18 14:59 ` Philip Balister
2009-11-18 15:22 ` Robert P. J. Day [this message]
2009-11-19 17:46 ` Robert P. J. Day
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0911181018010.22422@localhost \
--to=rpjday@crashcourse.ca \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.