Re: [gforth] Bug in install from new git repository?

[Dennis Ruffer]

Bernd,

I had just came to the same conclusions, but you must have libffi, since I
believe I couldn't compile without one of them on my ubuntu box.

It's the "make more" in BUILD-FROM-SCRATCH that is failing.

DaR

-----Original Message-----
From: Bernd Paysan [mailto:address@hidden 
Sent: Tuesday, March 12, 2013 7:20 AM
To: address@hidden
Cc: Dennis Ruffer
Subject: Re: [gforth] Bug in install from new git repository?

Am Montag, 11. März 2013, 19:50:19 schrieb Dennis Ruffer:
> Now that Bernd gave me the correct email address, I can ask these 
> questions over here and maybe get some clues.

Sure.

> in file included from *OS command line*:-1 in file included from 
> startup.fs:68
> savesys.fs:44: Undefined word
>     >>>throw-entry<<< main-task udp @ throw-entry next-task - /string 
> move
> ;Makefile:849: recipe for target `engine/prim.i' failed
> make: *** [engine/prim.i] Error 1
> make: *** Deleting file `engine/prim.i'
> 
> Guess I'm now fully rebuilt yet. ;(
> 
> Anyone have any clues?

Do a "make distclean" and then a BUILDFROMSCRATCH (./configure && make
should also do it).  Gforth is not always building with some debris from the
previous build lying around.  The assumption is: There's some Gforth
installed capable of running the cross compiler, and running vmgen, and the
rest is done with what results of the build process.  You should always be
able to build Gforth with the last stable release.

> Now that I got my Win7 PC back functional and updated to the git 
> repository, I get this from it:

Yes, as fflib and libffi aren't the primary C bindings any longer, quality
may suffer... especially, since I don't have any ffcall installed under
Linux anymore (not sure about libffi).

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/