Steve Swerling wrote:
> 
> Tim,
> 
> I think you may have some files locally that have not made it up to SF.
> It's been awhile since I've done any c programming, so I wouldn't bet my
> house on it. And I don't even own a house. But please read the following
> -- any help would be greatly appreciated to help me get the gamma image
> running on linux.
> 
> First, I did a fetch of the module "squeak" from SF.
> 
> Next, I did a generate using VMMakerTool with all plugins internal on an
> untainted 4599 image (after I pointed VMMaker at the "platforms"
> subdirectory that I checked out of SF).

Do you have the update relating to LargeFiles installed? I'm afraid I
forgot to mention it - that update is what provides the
positive64BitIntegerFor stuff.



> I got the following error
> message:
> 
>   "VMMaker could not make B2DPlugin as internal plugin because the
> exports list appears not to match".Interesting; that message is intended as a safety catch to make sure you have generated an exports file. You have to have an exports file for the internal plugin mechanism to work, so yo can see why it is important! I am driven to surmise that you must have tried to generate the internal plugins _without_ having generated the code vm first. Is that correct? Currently that can't work, though I imagine there might be a way to make it possible (it would involve some interesting gymnastics though).

 
> Next I tried to make. It broke on interp.c:
>   gnu-interp.c:1235: conflicting types for
> `readImageFromFileHeapSizeStartingAt'
>   ../src/vm/sq.h:309: previous declaration of
> `readImageFromFileHeapSizeStartingAt
> 
> I looked in those files for the funtion definitions for readImage... and
> found:
>   gnu-int: int readImageFromFileHeapSizeStartingAt(sqImageFile f,
> intdesiredHeapSize, int imageOffset);
>   sq.h: int readImageFromFileHeapSizeStartingAt(sqImageFile f,
> intdesiredHeapSize, off_t imageOffset);
> 
> The difference is the use of "off_t". Doing a search for "#define off_t"
> revealed it was defined as "int", but only in
> platforms/win32/vm/sqPlatformSpecific.h. (This is why I think something
> might be missing from SF). 
Yup, you got caught by the minor tumroil in the SF repository at the
moment. It is being fixed, and the off_t is replaced with a more
abstract name that can be defined for each platform without clashing
with assorted OS names.


> I would like to make a couple of suggestions for VMMaker. First, a
> little message to the transcript along the lines of "VMMaker finished
> generating" would by helpful.
I guess something like that might be useful. I think some indication in
the VMMakerTool would be better; one thingI want ot get to is catching
the assorted progress exceptions and make the progres bar fit into the
tool rather than splat all over the screen.

> Second, in the help window, you might tell
> unix users to put a script file called "sqconfigure" in their build
> directory that contains the following:
> at the moment.
>         SRCDIR=/Path/To/My/src
>         chmod 777 $SRCDIR/configure
>         chmod 777 $SRCDIR/util/mkMake
>         chmod 777 $SRCDIR/util/verstamp
>         $SRCDIR/configure
I didn't need to do that for some reason; oh of course, I already have a
copy of FileCopyPlugin on my machine. With luck, this will become a
non-issue soon since we expect to move to a non-copying-of-files strategy.

I'm not in a position to commit anything to SF for a couple of days
since I have to get on the road to pack up my milling machine and
deliver it to a buyer - no income means I'm having to start selling
stuff to pay the mortgage. Not fun :-( 

tim