SunOS4.x Notes

Anothny Martin <anthony.martin@gecm.com> submitted the following log of his efforts to build Ptolemy under SunOS4.1.3


Ant's log of building Ptolemy on Sparc SunOS 4.1.3
==================================================

<--- Bootstrapping egcs --->

$PTOLEMY/src/gnu/makefile	change --enable-shared to --disable-shared
$PTOLEMY/src/gnu/		make configure
$PTOLEMY/obj.sun4/gnu/make/	make
$PTOLEMY/obj.sun4/gnu/egcs/	make bootstrap
$PTOLEMY/obj.sun4/gnu/make/	make install
$PTOLEMY/obj.sun4/gnu/egcs/	make install
$PTOLEMY/bin/			ln -s ../gnu/sun4/bin/gcc gcc
$PTOLEMY/bin/			ln -s ../gnu/sun4/bin/g++ g++
$PTOLEMY/bin/			ln -s ../gnu/sun4/bin/make gmake

<--- gcc is built OK, tried & works, next build itcl --->

(When we tried building itcl2.2 we found we needed later version Xlibs...)

At this point we added X11R6.3 sources from xc-1.tar.gz to $PTOLEMY/src. The
config files were tweaked to build with gcc and install to $PTOLEMY/X11R6.3
omitting fonts and docs. A link was added in the gnu includes directory to 
the X11 includes. LD_LIBRARY_PATH has also been extended in the local .cshrc 
to to prepend the new X11 lib directory.

tcltk `configure' could not be persuaded to recognise our local Xlibs with
switches; it was necessary to fiddle with the makefiles. I thought I'd
include -DNeedFunctionPrototypes for good measure as the Xlib .h like it.

$PTOLEMY/gnu/sun4/lib/gcc-lib/sparc-sun-Sunos4.1.3_U1/egcs-2.90.27/include/
	added directory X11 & contents

$PTOLEMY/mk/config.sun4.mk
	changed X11_INCSPEC    = -I$(PTOLEMY)/X11R6.3/include -DNeedFunctionPrototypes
	changed X11_LIBSPEC    = -L$(PTOLEMY)/X11R6.3/lib -lX11
	changed X11EXT_LIBSPEC = -lXext -lSM -lICE
	changed SYSLIBS        = -lstdc++ $(CSYSLIBS)
	changed CC_STATIC      = 
	added   XMKMF          = $(PTOLEMY)/X11R6.3/bin/xmkmf
	added   MKDIRHIER      = $(PTOLEMY)/X11R6.3/bin/mkdirhier
	changed include $(ROOT)/mk/config-egcs.mk

$PTOLEMY/src/tcltk/		make configure

$PTOLEMY/obj.sun4/tcltk/itcl2.2/tk4.2/unix/Makefile 
	changed X11_LIB_SWITCHES = -L/users/ptolemy/X11R6.3/lib -lX11
	changed X11_INCLUDES     = -DNeedFunctionPrototypes

$PTOLEMY/obj.sun4/tcltk/itcl2.2/itk/unix/Makefile 
	changed X11_LIB_SWITCHES = -L/users/ptolemy/X11R6.3/lib -lX11
	changed X11_INCLUDES     = -DNeedFunctionPrototypes

$PTOLEMY/obj.sun4/tcltk		make bin
$PTOLEMY/obj.sun4/tcltk		make install

$PTOLEMY/tcltk/itcl/lib/itcl/iwidgets2.2.0/fileselectionbox.itk
		fix missing $ on $tcl_platform(...) bug

$PTOLEMY/tcltk/itcl/lib/itcl/iwidgets2.2.0/fileselectionbox.itk
		fix usual options bug 
		keep -background -borderwidth -cursor -elementborderwidth \
  		-foreground -highlightcolor -highlightthickness -labelfont

<--- itcl is built OK, tried & works --->
<--- tycho also tried & works, next build octtools --->

(When we tried building octtools we found we weren't using gnu make...)

Problem here is that -static prevents building the vem executable as
some Xlibs have no static .a version, only .so (Xaw).

Problems later building the kernel caused us to change the following,
but as vem was affected vem was also rebuilt (See note1).

$PTOLEMY/src/compat/ptolemy/compat.h changes:

/* octtools/Xpackages/rpc/appOct.c seems to need the next two,*/
/* it doesn't get them from stdio.h (Ant.)*/
/*extern long unsigned int 
fread(void *, long unsigned int, long unsigned int, FILE *); */
extern unsigned int fread(void *, unsigned int, unsigned int, FILE *);
/* Ant changed this */

/*extern long unsigned int 
fwrite(const void *, long unsigned int, long unsigned int, FILE *);*/
extern unsigned int fwrite(const void *, unsigned int, unsigned int, FILE *);
/* Ant changed this */

/* octtools/Xpackages/rpc/{appNet.c,serverNet.c} thor/analyzer/X11/event.c
   all call select */
/*extern select(int, fd_set *, fd_set *, fd_set *, struct timeval *);*/
extern int select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
/* Ant changed this */



$PTOLEMY/bin/			ln -s ../gnu/sun4/bin/make gmake
				setenv MAKE gmake
$PTOLEMY			gmake install_octtools

<--- octtools built OK, next build xv --->

(Now we find xv won't build with gmake... obj.sun4/xv/Makefile.std forgot 
to use $(MAKE) and gmake invokes make with -w and make barfs.)

$PTOLEMY			setenv MAKE make
$PTOLEMY			make install_xv

<--- xv built OK, tried & works (2.2? that's old?), next build gthreads --->

$PTOLEMY			setenv MAKE gmake
$PTOLEMY			make install_gthreads

<--- gthreads library built OK, next build pxgraph --->

(I don't want more greif building a JVM, AWT et al for Sparc SunOS4.1.3
with X11R6.3 just now. Gimme [incr tcl] & [incr tk] anyday. itcl3.0?
Java's much overrated. I'd choose Eiffel compiled to JVM...)

$PTOLEMY/bin/pxgraph		uncomment PT_USE_X11_PXGRAPH=yes

$PTOLEMY/src/pxgraph/pxgraph
	./configure --enable-gcc --x-libraries=$PTOLEMY/X11R6.3/lib

$PTOLEMY/src/pxgraph/pxgraph/makefile
	change X11_LIB_SWITCHES = -L/users/ptolemy/X11R6.3/lib -lX11
(configure --x-libraries=... doesn't seem to work??!)

$PTOLEMY/src/pxgraph/pxgraph	gmake
$PTOLEMY/src/pxgraph		gmake install

(One of my efforts to build the rest of ptolemy seems to have attempted
to build pxgraph, failed, and removed the bin.sun4/pxgraph.x11, and I had
to re-do the `gmake install'. This may be a problem with the makefile in
obj.sun4 ).

<--- pxgraph built OK, tried & works, now build pigi --->

To keep within available disk space some of the domains were dropped by
tweaking $PTOLEMY/obj.sun4/makefile. An override.mk was created to reflect
the domains required in pigiRpc.

My override.mk file:

PIGI = pigiRpc

	VERSION_DESC =	'With SDF,DDF,BDF,CGC,C50,CG56 domains'
	BDF =		1
	C50 =		1
	CGFULL =	1
	CG56 =		1
	CGCFULL =	1
	DDF =		1
#	DEFULL =	1
#	FSM = 		1
	HOF =		1
#	IPUS =		1
#	MDSDF =		1
#	PN =		1
#	ACS =		1
	SDFFULL =	1
#	SR =		1
#	SRCGC =		1
#	VHDLFULL =	1
#	VHDLB =		1

Owing to the statically compiled nature on Sun4, the executables
are very large and so only one executable was built, a pigiRpc with
the set of desired domains. I can add back a few more domains
later if I don't build many pigies. A set of pigi.* chews about 40M.
All ptcl.* pitcl.* pigiRpc.* tysh.* would take 160M-ish.

$PTOLEMY/obj.sun4/		gmake makefiles
$PTOLEMY/obj.sun4/kernel	gmake all
				gmake install
$PTOLEMY/obj.sun4/thread	gmake all
				gmake install
$PTOLEMY/obj.sun4/utils		gmake all
				gmake install
$PTOLEMY/obj.sun4/ptlang	gmake all
				gmake install
$PTOLEMY/obj.sun4/domains	gmake all
				gmake install
$PTOLEMY/obj.sun4/pigilib	gmake all
				gmake install
$PTOLEMY/obj.sun4/ptklib	gmake all
				gmake install
$PTOLEMY/obj.sun4/pigiRpc	gmake pigiRpc
				gmake install
$PTOLEMY/obj.sun4/filters	gmake all
				gmake install

Build complete.

I've also built a ptcl, pitcl, & tysh; they run but I've not kept them.
They don't seem to be that important. Tysh is neat but unfinished.

======================================

***Note1***

The following files would not compile:
/src/kernel/Clock.cc
/src/thread/posix/PosixThread.cc
/src/utils/libexttools/MathematicaIfc.cc
/src/utils/libptmathematica/MathematicaIfcFuns.cc
/src/domains/cg/kernel/CGUtilities.cc
/src/domains/cgc/kernel/CGCTarget.cc
/src/domains/cg56/targets/CGCXBase.cc
/src/domains/srcgc/kernel/SRCGCTarget.cc

This is due to contradictory declarations in the following files:

/src/compat/ptolemy/compat.h
`long unsigned int fwrite(const void *, long unsigned int, long unsigned int, struct _iobuf *)'
`long unsigned int fread(void *, long unsigned int, long unsigned int, struct _iobuf *)'

/users/ptolemy/gnu/sun4/lib/gcc-lib/sparc-sun-sunos4.1.3_U1/egcs-2.90.27/include/stdio.h
`unsigned int fwrite(const void *, unsigned int, unsigned int, struct _iobuf *)'
`unsigned int fread(void *, unsigned int, unsigned int, struct _iobuf *)'


gcc compiler:
`unsigned int' would appear to have come out of __SIZE_TYPE__, which
comes from _G_Config.h which is included by the gcc cpp by default.
size_t is typedef to __SIZE_TYPE__, but for some odd reason size_t 
isn't used to declare fread & fwrite in stdio.h .

SunOS cc compiler:
size_t is typedef to `unsigned int' in . This header is 
included within . fread & fwrite aren't in the header files.

Strict ANSI:
#include 
`size_t fread(...)'.

Posix:
???

We take it that gcc programs will use the old cc .so libraries at runtime.
And that the cc includes were used to build the libraries. So the types 
I must use for fread & fwrite must match the old cc headers. So gcc is 
right, ptolemy compat.h is wrong.

As they're in fact present in gcc stdio.h I don't see any point in
defining them in compat.h, if gcc is wrong we should fix gcc.

gcc may have the size right, but should have declared them with the typedef
size_t. Otherwise the prototypes don't match correctly in code which uses
size_t conforming to ANSI.

We also got lots of warnings about the declaration of select() in compat.h,
not serious but easy to fix.

Simply removing these declarations causes problems building vem as stdio.h 
isn't included where it should be. Making the declarations consistent with 
gcc was the solution.


Changes to $PTOLEMY/src/compat/ptolemy/compat.h follow:

/* octtools/Xpackages/rpc/appOct.c seems to need the next two (Ant.)*/
/*extern long unsigned int 
fread(void *, long unsigned int, long unsigned int, FILE *); */
extern unsigned int fread(void *, unsigned int, unsigned int, FILE *);
/* Ant changed this */

/*extern long unsigned int 
fwrite(const void *, long unsigned int, long unsigned int, FILE *);*/
extern unsigned int fwrite(const void *, unsigned int, unsigned int, FILE *);
/* Ant changed this */

/* octtools/Xpackages/rpc/{appNet.c,serverNet.c} thor/analyzer/X11/event.c
   all call select */
/*extern select(int, fd_set *, fd_set *, fd_set *, struct timeval *);*/
extern int select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
/* Ant changed this */



====================

***Note2***

This appears to be problems making the file: MatlabIfc.h.Auto

`/usr2/apl/ptolmy/ptolemy/obj.sun4/domains/sdf/matlab/stars'
gmake[5]: *** No rule to make target `../../../../../src/utils/libexttools/MatlabIfc.h.Auto', needed by `SDFMatlab.o'.  Stop.

(I haven't got matlab.)


====================

***Note3***

A number of problems were indicated by `ar' where object filenames were
being truncated. In a few cases they were no longer unique in the
library archive. We don't yet know how `ranlib' & `ld' will deal with 
these cases. (Using nm & grep on the `ranlib'bed library seems to
suggest that the classes are both still in there...)

This is a generic problem with the library archive file format on all
Unices; `ar's vary in whether they keep a `.o' on truncated filenames.
IMO the stars should be renamed. There also doesn't seem to be any
point prepending all the filenames with the domain.


ar cq libhofstars.a...
ar: filename HOFBaseHiOrdFn.o truncated to HOFBaseHiOrdFn.
ar: filename HOFBusDeinterleave.o truncated to HOFBusDeinterle
ar: filename HOFBusInterleave.o truncated to HOFBusInterleav
ar: filename HOFBusInterleave3.o truncated to HOFBusInterleav

### Note above! 2 objects truncated to HOFBusInterleav ###

ar cq libacsstars.a...
ar: filename ACSPrinterFPSim.o truncated to ACSPrinterFPSim
ar: filename ACSPolarToRect.o truncated to ACSPolarToRect.
ar: filename ACSPolarToRectFPSim.o truncated to ACSPolarToRectF
ar: filename ACSPolarToRectFixSim.o truncated to ACSPolarToRectF
ar: filename ACSXYgraphFPSim.o truncated to ACSXYgraphFPSim
ar: filename ACSXYgraphFixSim.o truncated to ACSXYgraphFixSi
ar: filename ACSPolarToRectFPCGC.o truncated to ACSPolarToRectF
ar: filename ACSXYgraphFPCGC.o truncated to ACSXYgraphFPCGC
ar: filename ACSXMGraphFPSim.o truncated to ACSXMGraphFPSim
ar: filename ACSXMGraphFixSim.o truncated to ACSXMGraphFixSi
ar: filename ACSXMGraphFPCGC.o truncated to ACSXMGraphFPCGC
ar: filename ACSPrinterFixSim.o truncated to ACSPrinterFixSi
ar: filename ACSConstFixSim.o truncated to ACSConstFixSim.
ar: filename ACSImpulseFixSim.o truncated to ACSImpulseFixSi
ar: filename ACSImpulseFPCGC.o truncated to ACSImpulseFPCGC
ar: filename ACSImpulseFPSim.o truncated to ACSImpulseFPSim
ar: filename ACSPrinterFPCGC.o truncated to ACSPrinterFPCGC

### another problem with ACSPolarToRectF here ###


Last updated 08/25/98, Send comments to www@ptolemy.eecs.berkeley.edu.