Here are some facts about building and compiling the software that might save people some hardship. I hope I successfully remembered everything. My sun already had gcc 2.8.1. It was running solaris 2.7 and was an ultra10. - choose one prefix directory when configuring(./configure --prefix=) the gnu software and stick with the same prefix for all the gnu tools. The binaries, shared items, and macros need to be in a common prefix directory for all the tools to work together as intended. I used /home/edaw/gnu/ as a prefix; subdirectories of this are made by the gnu install scripts. - the order of making the gnu tools is important. I made them in this order: m4, automake, autoconf, libtool, binutils, gcc-2.95.1. I did not need to install gzip, but I think installation of gzip is particularly easy. I didn't have to install gnu make either. - Check which make you have as default, using which make or make --version. If it's not gnu make (if gnu make, make --version should return a version number), you need that too. - between builds of the above packages, make the recently installed package available to the shell. I did this by adding to my .cshrc: setenv PATH "/home/edaw/gun/bin":${PATH} setenv LD_LIBRARY_PATH "/home/edaw/gnu/lib":${LD_LIBRARY_PATH} setenv MANPATH "/home/edaw/gnu/man:"${MANPATH} and (IMPORTANT) typing source ~/.cshrc after each successful build in the shell where I was typing the commands to build and make. This is necessary so the shell finds the new versions of the binaries and libraries. To check you can find the right version, use, eg, m4 --version. - this is the procedure I used for building gcc: 1) make a directory for the source code, eg /home/edaw/gcc_src 2) make a directory for the object code, eg /home/edaw/gcc_obj 3) download the source (eg gcc_2.95.1.tar.gz) and save the tarball in gcc_src 4) cd gcc_src 5) gunzip (or gzip -d) gcc_2.95.1.tar.gz 6) tar -xvf gcc_2.95.1.tar 7) hang on to gcc_2.95.1.tar in case you have to start again, if you have enough disk space 8) cd gcc_obj 9) sh -c '/home/edaw/gcc_src/gcc_2.95.1/configure --prefix=/home/edaw/gnu --enable-shared --enable-threads --with-gnu-ld=/home/edaw/gnu/bin/ld --with-gnu-as=/home/edaw/gnu/bin/as >configure.log 2>&1' & 10) to follow the configure script, type tail -f configure.log . You can ctrl C out of tail -f at any time without stopping the configure 11) sh -c 'make bootstrap > makebootstrap.log 2>&1' & same trick with tail -f to watch it. (takes about 1-2 hours) on an ultra10. 12) The sh -c bit just ensures that all the blurb generated by the configure / make process is kept in a file, not lost in a shell buffer. 13) make install if all this works. Should install the binaries in /home/edaw/gnu/bin/ (gcc, g++, ...etc) - any package that produces libraries called lib.a should be made to produce lib.so as well. This is accomplished with a configure --enable-shared for gcc (as above) and a configure -s for zlib. so stands for shared object. It is linked with the executable at run time. Hence ensure that your linker of choice is gnu ld (one of the gnu binutils), since the sun ld (usually /usr/ccs/bin/ld is not particularly compatible with the gnu products. The path to the /lib directory containing the .a and .so files should be added to $LD_LIBRARY_PATH in your .cshrc script. - zlib can be made by following the instructions that come with the package, and using configure -s so shared libraries are made. NOTE THAT THE FOLLOWING PROBLEM EXISTS: libz.so should be installed somewhere where the dmt build can find it. This means (unfortunately) you have to make the library somewhere obvious. I made it in /home/edaw/zlib ,but then added a soft link in /usr/local/lib/ . I needed to be root for this. I don't know of a cleaner workaround. To make a soft link cd /usr/local/lib become superuser ln -s /home/edaw/zlib/lib/libz.a libz.a ln -s /home/edaw/zlib/lib/libz.so libz.so exit superuser. In John's defense, this is a problem with the ldas frame library software and not john's dmt stuff. If you know of a more graceful fix, let me know. *Note* Users without superuser access should ask their system administrator to install zlib in the /usr/local. The problem of not being able to find zlib is getting fixed in the ldas distribution. I hope this fix will be included in the next release. - root should be rebuilt from the source using gcc version 2.95.1 . Here are John's instructions for doing this, which worked first time. I used version 2.22/10 1) Download Sun CC binaries and root source directory 2) set ROOTSYS, LD_LIBRARY_PATH and PATH variables 3) At this point I remove -I/usr/openwin/include from src/Makefile.solarisegcs. The reason is that my versions of the open (X)windows headers are missing the return type in the function prototypes. This is overlooked by gcc2.95.1 if the header is in /usr/include/X11/*.h but not if it's in /usr/openwin/include/X11/*.h You might try the standard make file, but if you get a lot of errors in X header files, try making sure that the headers are available from /usr/include/ and remove the include paths to /usr/openwin/include. 4) ./configure solarisegcs 5) make depend 6) make - before making dmt, define the following environment variables: setenv TARGET /home/edaw/dmt/ (or whatever target directory you want the dmt software in.) setenv DMTINPUT /home/edaw/frames/emptyfile.F setenv MACHTYPE sun setenv OSTYPE solaris - go into /home/edaw/dmt/RDist/src/Makefile. Change line 91 to SLIBsolaris = -L/usr/openwin/lib -L/opt/SUNWspro/lib -lXpm -lX11 - follow the make instructions under John's source tree in: /home/edaw/dmt/RDist/README . My only comment is to use the shell script again: sh -c ' > .log 2>&1' & when entering a command - as illustrated above for making gcc. That way if there is a problem you can go back and examine the output of make and configure. Cheers, Ed Daw 9th Feb 2000 (edaw@ligo.mit.edu)