salzman@RAND.ORG (Isaac Salzman) (01/05/90)
i don't know if i'd call these bugs - just some "glitches" i've
experienced in getting
R4 up and running. the environment is: Sun SS1, cgthree framebuffer,
Sun C compiler (-O
enabled).
this is not particular to any architecture. i like installing into a single tree:
/usr/local/X11/{bin,lib,man,include,...}. the ERRATA file in the
distribution directory
states the following:
Due to minor bugs in the configuration control, if you are trying to
install library files into a directory other than /usr/lib/X11, you'll
need to set XFILESEARCHPATHDEFAULT and ERRORDB in mit/config/site.def:
#ifndef XFILESEARCHPATHDEFAULT
#define XFILESEARCHPATHDEFAULT
"/usr/local/lib/X11/%L/%T/%N%S:/usr/local/lib/X11/%l/%T/%N%S:/usr/local/
lib/X11/%T/%N%S"
#endif
#ifndef ERRORDB
#define ERRORDB "/usr/local/lib/X11/XtErrorDB"
#endif
that doesn't seem to do any good. libXt is still looking for things in
/usr/lib/X11. so
here's what I did. in mit/lib/Xt/Imakefile:
#ifdef XFileSearchPathDefault
XFSP = XFileSearchPathDefault
XFSP_DEFINES = -DXFILESEARCHPATHDEFAULT=\"$(XFSP)\"
#endif
#ifdef ErrorDB
ERRORDB = ErrorDB
ERRORDB_DEFINES = -DERRORDB=\"$(ERRORDB)\"
#endif
DEFINES = AllocateLocalDefines $(ALIGN_DEFINES) \
$(XFSP_DEFINES) $(ERRORDB_DEFINES)
and in mit/config/site.def:
#ifndef XFileSearchPathDefault
#define XFileSearchPathDefault
"/usr/local/X11/lib/%L/%T/%N%S:/usr/local/X11/lib/%l/%T/%N%S:/usr/local/
X11/lib/%T/%N%S"
#endif
#ifndef ErrorDB
#define ErrorDB "/usr/local/X11/lib/XtErrorDB"
#endif
------
if you're planning on using gcc, there are a few things to be aware of.
i tried building
R4 with gcc 1.36. i also have g++ 1.36 installed, which includes gcc-ld - the GNU
loader. if gcc finds gcc-ld, it will use it over /bin/ld. that's just fine, except
gcc-ld does not know about dynamic linking. the end result is that you get all the
shared libraries built (since it always uses Sun cc for the lib's), but all the
executables are statically linked. link time took forever and the
executables were HUGE
(around 6-9meg for something linked with Xt, Xaw, Xmu...) since i
compiled with -g and
-O. stripping took care of the size problem.
there is a gcc problem is dbm calls - same one that existed in R3. the server
(mit/server/os/4.2bsd/oscolor.c) and rgb (mit/rgb/rgb.c) both make dbm calls. gcc is
supposed to deal with that ok (-fpcc-struct-return), but there appears
to be a bug in
gcc for sparc. so i had to compile those to .c's with Sun cc.
one more gcc problem. you don't want INCLUDE_ALLOCA_H for gcc on a sparc machine.
mit/server/include/os.h does this
#ifdef __GNUC__
#define alloca __builtin_alloca
...
#endif
which is exatly what's in /usr/include/alloca.h. so you get a bunch of warnings. one
solution - edit sun.cf and change the code that deals with the ALLOCA stuff to the
following: (so it only includes if if NOT using gcc)
/* define this as you like for server compilation */
#if (OSMajorVersion >= 4 || defined(SparcArchitecture)) && HasGcc == 0
#define AllocateLocalDefines -DINCLUDE_ALLOCA_H
#else
#define AllocateLocalDefines /**/
#endif
by the way, if you're using gcc, you have to turn it on in sun.cf. if you only set
HasGcc to YES in site.def, things won't work right since it's included
after sun.cf. the
end result is that the libraries are build with gcc when they must be
built with cc in
order to create the shared libraries....
overall, there's no real advantage to using gcc on sparc. however, sun3's are a
different story....
and for those having problems with shared lib's and this:
ld.so: libXmu.so.4: not found
make sure the LD_LIBRARY_PATH environment variable is set to wherever
you installed the
libraries (i.e. setenv LD_LIBRARY_PATH /usr/local/lib:/usr/lib), or run ldconfig as
root....
--
* Isaac J. Salzman ----
* The RAND Corporation - Information Sciences Dept. /o o/ /
* 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | |
* AT&T : +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/
* Internet : salzman@rand.org / | |
* UUCP : !uunet!rand.org!salzman | | |