Compile_wont.txt
----------------
		" You did edit MK_SPIN_site ... "

	All of my versions do compile, but occasionally the scripts
	are broken. Compile can be a problem when working on 
	a different compiler version, or OS.

	The SPIN makefiles are "almost identical" to the SP makefiles,
	using VPATH. I don't do "make depend" "make clean" or pure
	or even install. If you keep the log from the make, it should
	strongly resemble the log from SP's make session. You can
	build SP in-situ, without intefering with SPIN. If you adjust
	SP's config.h file, it should have the same effect on both.

	The VPATH use by the makefile is now more location independent,
	but it does rely on the relatice existance of ../SPIN_makefiles/
	and also on the abolute path edited into MK_SPIN_site.

	You must use ftp.gnu.org's make, because I like the syntax:
	LIST += ITEM

	If you get "set_new_handler" as the only missing symbol during
	linkage, edit config.h. If you get a long list of missing symbols,
	you are using an old gcc-2.95 on linux. If you get many compilation
	errors, you are using gcc-2.95 on another OS, with different
	include files. If you get missing symbol "eh_pc"for SPIN but not
	for nsgmls, you are looking at something that fools me too. Maybe
	theres an exception that needs a try.

	egcs-1.1.2 on Solaris-7 is worth a try.

	If you can get SP compiled using 2-95+ on HP-UX, then
	call me immediately, I need an excuse to work on this
	during daylight hours. TIA.
		      
	Since I dont use "make depend", when you play with a SPIN header
	file, all users of that file wont be re-compiled. Adding a data field
	or function can change the expected layout and cause a sig-seg.
	Simply delete SPIN_py/*.o and recompile.

	DOS users ... creating DLL's with gcc-2.9 to work with
	stripped DLL's created by MS-VC can be a bit of an exercise.
	Plus there is an ever present problem of using different malloc/free
	pairs in different modules. Lets hope that gcc-3 makes it as
	simple as gcc -shared, Good luck!

