jos@ele.tue.nl (Jos van Eijndhoven) (10/12/89)
With this message I would like to report on the installation
of the public domain X11.3 sources on our alliant FX/8,
running concentrix 5.0.0 (a BSD4.3 look alike) and the
alliant FX/C 2.0.18 (ansi) C compiler.
Others who intend to do the same job might save valuable time.
Furthermore I hope that new versions of X11 and FX/C don't have
the same errors anymore.
Several problems arised and were solved, originating from either
bugs in X11.3 or bugs in the C compiler.
The use of FX/C (cc) was preferred over the also available portable
C compiler (pcc) because it generates compacter and faster code.
Pcc shows NONE of the real fxc bugs listed below!
However it has others ......
We use X11 on the alliant to offer a windowing
environment to the alliant users, who almost all have an Apollo
workstation on their desk. Furthermore it (of course) enables
programs with graphic output to be run on the alliant.
Older versions of X were on our alliant also. The (re)compilation
of X11.3 became urgent, because the update from concentrix 4.0 to 5.0
prevented the successfull compilation and linking of new clients
with the old X11 libraries.
The alliant is not actively supported as target machine for X11
on the original (MIT) distribution.
Below I will summarize the different steps I made for a correct
installation in the same way as is intended for fully supported machines.
Our copy of the sources was distributed by James Watson from
adasoft in Switzerland (jw@pan.uucp), which contains besides the
original sources also all the patches and postings upto
tape-generation date.
--1-- (unpacking)
Unpacking the tape with uncompress and tar works fine.
In the following I will assume that the tape is
read under /usr/X11.3, as is the default. To save on disk space
the subdirs server and fonts can be freely removed: Since no display
is attached to the alliant, no server will be built and no fonts
are needed.
--2-- (alliant support)
To add alliant support, a file 'Alliant.macros' should be added in
util/imake.includes. The actual file that I used is listed at the bottom
of this message.
It states that no server is to be made.
It assumes that fxc is available as /bin/cc.
The compiler options are set to '-Og -double -DUNIXCPP'.
We did '-Og' for a conventional global optimisation only.
Alternatively one could experiment with '-Ogi', for inline expansion.
'-double' is added for backwards compatibility with old K&R C.
'-DUNIXCPP' is added to get an awfull define of 'SIZEOF' working.
(X11/Xmd.h, line 60).
How @#&$?~@#! can someone write such code!
Isn't MIT ashamed to have its name attached to this?
This SIZEOF works only under two assumptions:
a) An undocumented and thus not standardized bug in some cpp
which replaces /*comment*/ by nothing in stead of "white space"
as K&R C states (pp 179).
b) An undocumented and thus not standardized ordering such that
replacement of #defined names comes AFTER this comment removal.
Furthermore the ansi type of replacement fails.
Probably this is to be considered a bug in fx/c.
--3-- (alliant support)
A few lines must be inserted in 'util/imake.includes/Imake.tmpl'
to complete Alliant support:
#ifdef alliant
#define MacroIncludeFile "Alliant.macros"
#define MacroFile Alliant.macros
#undef alliant
#define AlliantArchitecture
#endif
These lines should appear somewhere between the corresponding lines
for the other architectures.
--4-- (X11 limitation)
To bootstrap the generation of the Makefiles, one Makefile
should (and can) be edited.
Modify in util/imake/Makefile the assignment of CDEBUGFLAGS to:
CDEBUGFLAGS = -Og -D'ccflags=""'
Watch out for the different quotes!
Actually a variable BOOTSTRAPCFLAGS was provided for this bootstrapping.
However this feature doesn't allow for the removal of the omnipresent '-O'
flag, which is highly undesired with fx/c.
--5-- (X11 bug, fxc bug)
A few files have a ; attached after the } closing a function definition.
This is a plain C syntax error.
However fx/c chrashes on this without suitable message.
All these occurences are found by a search for '^};' .
Be aware that this search also retrieves valid (mandatory) }; for
instance after typedefs. I repaired the following lines:
lib/Xt/Converters.c:124 142 176 194 229 257 323 448 471 494 553 677 691 705
lib/Xt/Event.c:527
lib/Xt/InitialI.h:143
--6-- (fxc bug)
Fx/c gives a syntax error at '}else' when there is no separating
white space in between.
HOW IS THIS POSSIBLE ??????
Don't they separate lexical and syntactical analysis ???????
I inserted spaces in the following lines:
lib/Xt/Manage.c:87
lib/Xt/NextEvent.c:435
lib/Xt/NextEvent.c:451
lib/Xt/Resources.c:1079
--7-- (fxc bug)
fx/c cannot cope with the initialization of an array of pointers in:
lib/X/XPutImage.c:403:static int (*(SwapFunction[12][12]))() = {
The problem is solved by eliminating the inner () which are redundant:
lib/X/XPutImage.c:403:static int (*SwapFunction[12][12])() = {
--8-- (fxc bug)
fx/c (actually fxc0) limits the depth of #include nestings to 10.
However in lib/Xt I observed depths upto level 12, and in clients/xman even
upto level 15!
Its message is 'unreasonable include depth'. It is probably right that
X11.3 and/or bsd4.3 are unreasonable sources, but this should not
prevent fx/c from doing its job.
I solved this by inserting two lines:
lib/Xt/Intrinsic.h:32:#include <sys/mplock.h>
X11/Xos.h:30:#include <sys/mplock.h>
By including these files before others, the inclusion is
done at a lower level. Further inclusions of the same file at higher
depths are now automatically skipped, due to an #ifdef check.
Since this file <sys/mplock.h> seems alliant specific, I recommand
to enclose these #include lines between #ifdef alliant -- #endif pairs.
I strongly advises that alliant changes this maximum include depth,
since (at least) 7 levels are already occupied by concentrix itself!
(sys/file.h -> sys/fslock.h -> sys/mplock.h -> sys/syslockdef.h ->
sys/param.h -> signal.h -> machine/reg.h)
--9-- (fxc bug)
Basically you are ready now to ask for 'make World' in the X11
root directory (/usr/X11.3).
However one file (lib/Xt/Resources.c) compiles silently but has
a bug in its object. Although there will be surely a small patch
to solve this, I didn't have time to locate it.
Compiling this file with pcc -O gives correct code.
However this should be done in the correct order with respect to the
rest of X11.
The easiest way is probably keeping track of the activities
of 'make World' running in the background.
Now as soon as it starts compiling (one of) the lib/X* libraries,
one can by hand cd to lib/Xt and type there:
make 'CC=pcc' 'CDEBUGFLAGS=-O' Resources.o
This should be done BEFORE any clients are (compiled and) linked.
It should be done BEFORE compiling in lib/Xt is finished, otherwise
one should remake the object library in lib/Xt:
make libXt.a
It should be done AFTER 'make World' has done its 'make clean'.
It should be done AFTER 'make' has run in X11/.
and -of course- after 'make Makefiles' and 'make depend'.
If anybody can send me a message, repairing the bug in Resources.c,
I would be very grateful!
---------------------------------------------------------------
Good Luck with
X11.3 on your Alliant!
---------------------------------------------------------------
I didn't take the effort to report these fxc problems to Alliant.
Since they deliver X11(.2?) as product themselves, I assume that
they have observed all these already.
However I still hope that someone there gets this message,
and makes sure that these problems are solved in a new FX/C release,
of which I heard rumours that it might be released soon.....
Jos van Eijndhoven
Dept. of Electrical Engineering
Eindhoven University of Technology
PO box 513
5600 MB Eindhoven
The Netherlands
email: jos@ele.tue.nl
****************************************************************
**************** below is listed our file **********************
*********** util/imake.includes/Alliant.macros *****************
/**/# platform: Alliant FX/8, Alliant.macros by JvE, oct 5 1989
/**/# operating system Concentrix 5.0.0; compiler FX/C 2.0.18
BOOTSTRAPCFLAGS =
AS = as
CC = cc
CPP = /lib/cpp
LD = ld
LINT = lint
INSTALL = install -s
TAGS = ctags
RM = rm -f
MV = mv
LN = ln -s
RANLIB = ranlib
RANLIBINSTFLAGS = -t
AR = ar clq
LS = ls
LINTOPTS = -axz
LINTLIBFLAG = -C
MAKE = make
STD_CPP_DEFINES = -DUNIXCPP
STD_DEFINES = -DUNIXCPP
#define OptimizedCDebugFlags -Og -double
#define BuildServer NO
#define LibraryDefines -DUNIXCPP
#define ConnectionFlags -DTCPCONN -DUNIXCONN
#define ExpandManNames YESrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/13/89)
How @#&$?~@#! can someone write such code!
Isn't MIT ashamed to have its name attached to this?
Not in the slightest. Perhaps you should try writing a system as
large as what we distribute, and have it compile and run with at
most minor modifications on as many systems as for what we distribute ...
This SIZEOF works only under two assumptions:
If it doesn't work for you, fix it and send us the diffs, or get an
ANSI compiler.
Furthermore the ansi type of replacement fails.
Probably this is to be considered a bug in fx/c.
No, it's a trivial bug in the macros. Since we didn't really have
an ANSI compiler to properly test with, this fell through the cracks.casey@gauss.llnl.gov (Casey Leedom) (10/23/89)
Well, you certainly had a lot of problems getting X.V11R3 up. I suggest you try again, but this time with GCC. It works a lot better. Alliant's C compiler is fundamentally worthless. You can never tell when it's going to compile something correctly. GCC is a lot more robust. Also, one item you listed as a C usage bug in X.V11R3, semicolons following function definitions, is perfectly legal (though disgusting) C. It forms an empty C declaration. You can get the patches to make GCC work on the Alliant from Eugene Brooks (brooks@maddog.llnl.gov) if they're not already in the main GCC distribution (I don't keep up with it, so I don't know). I can send you what little I had to do to get X.V11R3 up on the Alliant (the same code works under both Concentrix 4.0 and 5.0). Casey
casey@gauss.llnl.gov (Casey Leedom) (10/24/89)
| From: prl@iis.ethz.ch (Peter Lamb) | | > From: casey@lll-crg.llnl.gov (Casey Leedom) | > | > One item you listed as a C usage bug in X.V11R3, semicolons following | > function definitions, is perfectly legal (though disgusting) C. It forms | > an empty C declaration. | | [Excerpts from early ANSI C drafts and browsings through K&R showing that | null declarations aren't legal in K&R C or ANSI C.] Ack, you're probably right. I knew I shouldn't have mailed that off before going into work to check out my K&R. I just thought I remembered seeing a syntactic path through the syntactic description that allowed a null declaration and then I figured ``gcc -ansi -pedantic'' would object if it wasn't legal C (it didn't complain). Chalk it up to another case of jumping without looking. Please excuse the tangent. Casey