Brian,
Does anyone know why sqFilePrims.o, sqSoundPrims.o, sqUnixNetwork.o, and sqXWindow.c apparently aren't reading in their header file "sq.h" [...] The sq.h file definitions don't seem to be getting into the above files, though the #include "sq.h" is at the top of each file.
Here are some things to try. Compile with "-H" to see if the preprocessor is including the right "sq.h". Compile with "-E" to check the output from the preprocessor to see if it looks reasonable -- you should be able to see the definitions for "int success(int);", and so on, in the pre-processed output of sqFilePrims.c and friends. Run "nm" on "sqFilePrims.o" and "interp.o" and pipe it into "grep _success": the former should have a symbol table entry of type "U" for _success, and the latter an entry of type "T". If all of that checks out okay, then I'm baffled.
You might want to double-check that the "make" program is linking all the required ".o" files, or try linking them manually:
gcc -o Squeak *.o -lX11 -lXext -lm
and maybe with the "-v" flag to see precisely which options the driver is passing to the various compilation stages.
A Squeak Makefile is needed to work on a NetBSD-1.3 unix system which has not yet got a port of Squeak. [...] gcc generated system info through gcc -E -dM c.c
This will print a bunch of symbols, amongst which you should choose one (or more) to identify the platform. (You could equally well discover these by running "gcc -v" which will print the path to the "specs" file, in which you will find a list of the platform-specific definitions that gcc is using on your platform, immediately after the line "*cpp:".)
Once you have rectified the linking problems I suggest you copy the iX86/FreeBSD portion of the config file, change the symbols in the #if defined(...) lines to check for your platform, and alter the #defines and #undefs to suite the M68K instead of the Pentium. My guess is that the OS stuff is all the same, and the CPU stuff is all the opposite way round except for DOUBLE_WORD_ALIGNMENT (if this is incorrect then you'll get a SEGV the first time the Squeak tries to read or write a Float):
#if defined(__BSD__) && defined(__m68k) /* 68k/BSD */ # if defined(SQ_CONFIG_DONE) # error configuration conflict # endif # undef HAS_D_NAMLEN # undef HAS_TIMEZONE # undef HAS_ON_EXIT # define HAS_MSB_FIRST /* changed */ # undef DOUBLE_WORD_ALIGNMENT # undef DOUBLE_WORD_ORDER /* changed */ # define JUMP_ALIGN_STRICT /* changed */ # define SQ_CONFIG_DONE #endif
I'm not 100% certain about DOUBLE_WORD_ORDER -- you'll have to try it both ways and see which one works. (The image might even come up, and restore the display, with the wrong setting. The first thing you should try is "print it" on "Float pi", and if the value is right then then flag is right.)
Good luck!
Ian
Does anyone know why sqFilePrims.o, sqSoundPrims.o, sqUnixNetwork.o, and sqXWindow.c apparently aren't reading in their header file "sq.h" [...] The sq.h file definitions don't seem to be getting into the above files, though the #include "sq.h" is at the top of each file.
One reason I have seen for this appearing to happen is the line-ends being wrong. Some compilers will read the file but 'ignore' it. They don't report not being able to open the file, but they behave as if it wasn't there!
IIRC the 'fresh' sq.h file is CR line-end; if, for example you try to use it with M$ C++ Developer Stupifier it will usually screw up.
tim
Tim Rowledge wrote:
One reason I have seen for this appearing to happen is the line-ends being wrong. Some compilers will read the file but 'ignore' it. They don't report not being able to open the file, but they behave as if it wasn't there!
Something similar happens with gcc 2.7.2 on OS/2 when compiling interp.c. gcc complains on the first line if fed with the generated interp.c, but if I add an empty line at the very top of the file, everything seems OK. (In fact I don't know why this is so.)
Boris
squeak-dev@lists.squeakfoundation.org