Due to various peculiarities and deficiencies (or sometimes excessive cleverness) of different operating systems some need special treatment.
SM seems to build without problem on alphas running OSF/1. Unfortunately, bison does not, so if you need to rebuild control.c from control.y you will need to obtain a more recent version of bison than the one that we supply; version 1.18 is known to work. It may be found on any of the GNU source sites (for example prep.ai.mit.edu in /pub/gnu).
If you don't expect to change the SM grammar (as is probably the case) then you can avoid this problem by saving copies of control.c and control.h from the distribution, and then when make fails to build new ones, copying the saved ones to the src directory (do not move them! Their modification dates must be updated).
The easiest way to use your new bison is to go to the src directory and type
make rm -f control.c ; YACC="bison -y" control.c
An alternative would be to change the definition of YACC directly in the Makefile and rebuild (remembering to remove the old control.c).
SM should build smoothly on Berkeley systems as most of its recent development has been on such machines.
This information is based on reports from an Alliant FX/80 running Concentrix 5.6.00.
The compiler options in the Makefile should be set to
CC = fxc
CFLAGS = -Og -nc -g -Isrc
SM has been built with version 2.2 of the FX/C C compiler. It is not clear if there would be any significant difficulty with an earlier version.
Define _POSIX_SOURCE in `options.h', and make sure to compile with
cc -D__STDC__=1 -Dunix
(or add the definition of __STDC__ and unix to CFLAGS in
`sm/Makefile',
or carefully define the proper things in `options.h').
If you are using
the X11 driver there is a problem with `/usr/include/strings.h', which
is included by `X11/Xos.h'. The easiest
workaround is to define SYSV when compiling x11.c (use -DSYSV
on cc's command line, or edit `x11.c' to #define SYSV).
It is probably OK to simply
add -DSYSV when you add -D__STDC__=1 to CFLAGS).
Compile with
cc -Dhp
We have had reports that the ANSI version of the compiler gives problems; if you use it successfully please let us know.
SM can be built on PC's using Borland's C++, version 3.0 or later. For these versions, the `.sm' file has been renamed to `sm.rc' due to PC file system restrictions (and is distributed as `sm_rc' so as not to confuse unix users).
We have seen problems with the optimizer in some releases of Borland's
compiler. The Makefile.dos as distributed uses -O1. We also use
-ml. If you use some other combination of switches, and
get better results, please let us know.
If you don't have a working version of bison (you can get the
executable from various places) and don't feel like building one, make
sure that the files `src/control.c' and `src/control.h' are
younger than `src/control.y'. If this is true, bison
is not required.
You'll have to edit `options.h' to define which devices you want
to use (If anyone wants to write a script like set_opts, please send
us a copy!). The graphics devices available are
bgi, the Borland Graphics Interface, and win or msw,
the Microsoft Windows API.
These two
versions produce files with the same name (`SM.EXE', `*.OBJ')
but the object
files are incompatible. If you want to build both versions, make sure
you clean up between the makes (with make empty).
Currently (due to lack of time and interest) the author of the PC port does not support the Plain version; he only checks that the Windows version compiles and runs.
You should then be able to say make -fMakefile.dos in the top
level directory, or make -fMakefile.dos -DWIN if you want the windows
version. Note that you must specify twice whether you want the plain DOS
or the Windows version; this is due to the general structure of sm
and will not be changed (uhm, fixed).
The drivers use some svga code from the net. It's in the directory `sm/dos', and you'll have to move the files to the proper places before you can build SM (for example, to build the bgi driver, you'd typically copy the `.h' files to `/borlandc/include' and the `.bgi' to `/borlandc/bgi'). There should be no problem using more recent versions, if you can find them.
When you run SM with device bgi,
the graphics drivers, the `.bgi' files, are assumed to be in a directory
given by the DOS BGIPATH environment variable; alternatively you
can specify a bgipath variable in your `sm.rc' file.
If you use devices that need the stand-alone programme rasterise
you'll find that SM doesn't leave enough memory to run both at once. It
would be possible to rewrite rasterise to use much less memory, but as
this isn't a real concern on unix boxes this is unlikely to happen soon.
You'll have to exit SM (maybe using the save command to save your
environment) before you can submit your plots. One way to remember to do
this is to put a line
BIN = echo "Remember to run the command: "
in your private graphcap file.
I don't know much about this port, so comments would be welcome.
The build is done with the set of Makefiles called `Makefile.os2'.
The device name is os2pm, and the terminal type os2pc.
SM can be built on IBM PCs ( or compatibles ) running OS/2 2.X using Borland's C++ compiler for OS/2 version 1.5. ( See below if you have version 1.0 ) On screen graphics output is provided by a separate Presentation Manager program, sm_pmdev.exe, which is spawned by the SM command line session.
Installation Instructions:
make -fmakefile.os2 allThis should build everything and place the two executables, sm.exe and sm_pmdev.exe in the sm\src\ directory. If you will be using a raster device you must also make rasterise.exe with the command
make -fmakefile.os2 rasterise.exeThis will build rasterise.exe and place in in the sm\ directory.
SET HOME=D:\efgh\Makes D:\efgh\ your HOME directory
SET SMPATH=. ~ E:\abcd\ D:\In this example SM will look for the .sm file first in the current directory, then in HOME, then E:\abcd\ and last in D:\ (Remember, after placing the SET statemanet in the config.sys file, the system must be re-booted for the definition to take effect )
temp_dir.
sm.exe, sm_pmdev.exe, and rasterise.exe (if you want
to use a raster printer ) to a directory included in the
system's PATH variable.
If all is well you are ready to run. After starting SM the statement device os2pm ( or device pm ) should produce a Presentation Manger graphics window. By default retain mode is enabled for this window so it can be resized by grabbing an edge or corner, and the drawing will scale accordingly. When minimized the graphics window will appear as an icon in the Minimized Window Viewer. Use help os2pm for futher information on this driver.
Since the directory separator in OS\2 is interpreted as an special character in the graphcap file, specifying directories explicitly can lead to problems. A convenient way to enable the raster device is to use a :SY entry in graphcap something like
:SY= rasterise -r $0 $F $F.tmp \n PRINT /B $F.tmp \n del $F.tmp:
and be sure your .sm file has a line like
temp_dir = d:\temp\
Currently the only incompatability with V1.0 of the Borland C++ for OS/2 compiler arises from a Borland error in the declaration of signal() function. This can be remedied by adding the lines
#if (defined(__BORLANDC__ ) && defined(__OS2__)) typedef void (__cdecl *pCatch )(int); #define signal(a,b) signal((a),(pCatch)(b)) #define SIGBUS SIGSEGV #endif
after the #include statements in sm\src\sm_main.c .
Compile using CC=c89 -Drs6000 in `sm/Makefile'.
In versions of AIX prior to 3.2, you may have to add
-bnodelcsect to the
LDFLAGS passed to bison in `sm/src/Makefile', i.e.
$(MAKE) CC="$(CC)" CFLAGS="-c" LDFLAGS="-s -bnodelcsect" bison
(This is a required by a bug in their compiler)
The RS/6000 supports Silicon Graphic's GL graphics as well as X11.
If you want to call SM from fortran you must explicitly link with the
C runtime library (add a -lc to the end of the linker flags,
which are called LDFLAGS in the sample Makefile in the
`callable' directory), or else the brain-dead system will find
its own function getenv not the standard C function with that name.
Compile using CC=cc -ansiposix -Dsgi in `sm/Makefile'. If you want
SM to use GL routines for graphics, define SGI in `options.h'; X11
will work just as well (or you could use both). As SGI doesn't provide
a termcap file you'll have to use ours; the default `.sm' file provided
should include it.
There is a bug in the mathematics library (bugid 124930); the workaround is to use -O when compiling SM. If you want to know if your system has the bug, start SM and say:
set x=0,10 set x=10+0*x set y=lg(x) print { x y }
If you have the bug, it should be pretty clear!
Sun has traditionally had a BSD-unix operating system, but with Solaris it has switched to the System V camp.
If you are running Openwindows and not the X Consortium X11 distribution,
you will have to tell the makefiles where to find the X11 include files
and libraries. Openwindows has them (by default - your system manager
may have moved them) in `/usr/openwin/include' and
`/usr/openwin/lib', respectively. So you need to add
-I/usr/openwin/include to CFLAGS, and
-L/usr/openwin/lib to LDFLAGS. You may also have to
define the environmental variable LD_LIBRARY_PATH to be
/usr/openwin/lib.
When compiling the sunview device (an obsolescent sun windowing system) you may get warnings if you are using the gcc C compiler because sun's system headers are not ansi compliant. You should ignore them, the device will work perfectly well.
The default configuration is for a BSD-derived unix. To compile for
System V you should define SYS_V in the options.h file. Because SyS V
has no ranlib command (what? ranlib?), you should edit the Makefile in
sm/src to define RANLIB as "sh /dev/null". On (some?) HP machines, if you
want to use gcc you may need to compile get1char.c with the -traditional
flag, as the system header files are broken (or you can run the gcc script
fixincludes).
At least some SyS_V machines don't have the system call select.
If this describes you don't panic. Define NO_SELECT in `options.h'
and proceed. This has some minor side effects that could lead to problems
with refreshing display windows under (for example) X Windows.
There are workarounds (e.g. you will have to
make sure that the X-Windows server has backing store), if you have trouble
send us mail.
Many Sys_V machines don't have a termcap file. We provide a small one for you, but if you have weird terminals you may have to figure out how to translate terminfo back to termcap; when you have succeeded (or given up) please send us mail. An alternative might be to look at some system (such as a sun) with an extensive termcap file.
SM seems to build without problem under Ultrix.
Most (but not all) of this is for those poor souls without MMS.
To make SM first set your default directory to `[sm]'. You should look at (and maybe edit) the file `[sm.src]options.h' to choose in your favourite device drivers. If one of those is vaxuis, you will also have to edit `[sm.src]sm.opt'. The comments in `options.h' tell you how to edit the linker options file.
Then if you are running on an old-style VMS system, execute the command file `compile.com', i.e.
$ @compile
This will compile all the routines in the subdirectories, including making `bison.exe' and the font table. You can also just make parts of SM, e.g.
@compile bison
@compile fonts
See the comments at the top of `compile.com' for a list
If you are using an Alpha and OpenVMS, the first argument to `compile.com'
should be the word alpha, viz
@compile alpha
or
@compile alpha fonts
If you have MMS, you have to edit the `descrip.mms' files in the top level directory and in `/src' to choose the proper compiler flags, and to set the name of the linker options file. We hope that we have provided enough comments to make this easy.
Once these changes have been made, you can simply say
$ mms all
in the `[sm]' directory, and make the program that way (after editing `[sm.src]options.h' as before)
You may have quota problems when you try to run SM. The following is a report from a VMS site on what quotas were found sufficient for running SM (n.b. - may not be up to date):
Subprocess limit > 2
Buffered I/O byte count quota > 5000
Direct I/O limit 18
Buffered I/O limit 18
AST limit 22
Paging file quota largish, we reckon > 10k
Default page fault cluster 64
There is a command file to allow you to run SM as a kept command,
called `kept_SM.com'. To use it, define a foreign command that runs SM
(e.g. _sm :== $ disk:[sm.src]sm.exe), and say @kept_SM _sm.
Then you can suspend SM with the ^Z key (or whatever you decided to
use -- see the section on the editor), and restart it with the same command.
You will also need to define a foreign command to run `rasterise.exe' if you have any raster devices.
Because SM uses the `termcap' file invented by Unix, you'll need a copy yourselves. There is a small one in the main source directory and you'll have to make sure that either there is a termcap entry in the `.sm' file pointing to it (better), or a logical variable.
Go to the first, previous, next, last section, table of contents.