Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!eru!luth!sunic!bmc.uu.se!kuling!jand From: jand@kuling.UUCP (Jan Dj{rv) Newsgroups: comp.sys.hp Subject: How to make gcc and g++ on HP-UX 7.0. (Summary) Message-ID: <1583@kuling.UUCP> Date: 4 Jul 90 08:48:56 GMT Reply-To: jand@kuling.UUCP (Jan Dj{rv) Organization: Dept. of Computer Systems, Uppsala University, Sweden Lines: 117 I submitted an article sometime ago about gcc on HP-UX 7.0. I received many useful hints. Those who replied where Paul Anderson Dave Von Bank Bob Desinger Glen R. Engel Kaleb Keithley Tom Lane Paul Raveling Thanks everyone. Tom Lane supplied me with diffs that made it possible to make gcc (included in a separate posting). There are many problems in making gcc. HP-UX malloc (in libc.a) and alloca (in libPW.a) seems to be broken. Fortunately there's an alloca distributed with gcc (1.37.1). Kaleb, Glen and Tom pointed this out to me. Kaleb writes: Uncomment ALLOCA=alloca.o in the Makefile. gcc-1.37.1 comes with alloca.c; this will force alloca.c to be compiled. I haven't tried this on HPUX, but Sun's alloca is broken, and requires the same fix. The INSTALL file appears to be outdated; it still says 1.36, and the reference to alloca seems to predate even 1.36, as 1.36 came with alloca.c. Bob writes this about alloca and HP: A year or so I looked at the -lPW alloca source on HP-UX for the Series 800; it was identical to the GNU alloca. They were both based on Doug Gwyn's (or was it Ron Natalie's?) public-domain code. But I guess either the Series 300 version is different, or else GNU and HP-UX sources diverged. GNU:s alloca is based on Doug Gwyn's alloca. If you are making g++ amd libg++ you must use GNU:s malloc or -lmalloc when compiling. I found that g++ produces incorrect code for functions declared inline if standard malloc is used. Many tests for libg++ will fail if standard malloc is used. I've found that the malloc that comes with g++ and gdb works best. Use it when compiling gcc, g++ and libg++. Do not use the malloc that comes with libg++. It also makes some tests fail. I think HP shuld merge -lmalloc into libc. Having two malloc:s is only confusing. A final word on alloca from Tom: NOTE: gcc -O is VERY VERY slow with the portable alloca. I find it fastest to build stage2 without -O, then to make a production third stage with -O turned on. HP:s setvbuf appears to be broken. This affects gas. When setting linebuffering on a file, the first character of that file is lost. No rewinding or seeks can undo that fact. Gas inserts a '#NO_APP' comment (# indicates comment) but the # is lost and gas breaks. There is a warning about this in the Makefile of gas-1.36. GNU:s ld has problems. If it finds that a .o file of an archive is needed it loads all symbols from that .o file, regardless if some of those symbols have been defined previously. This affects programs which defines there own exit. A workaround for this condition is to rearrange some symbols of libc.a (included in the patches). However, this does not solve all the problems, Tom writes: HP's ld seems to be able to deal with libraries containing symbols that are also defined elsewhere, whereas gnu-ld just barfs. I wanted to build emacs with X support, and HP's X11R3 libraries contain some subroutines that have the same names as stuff in emacs. This can become a major problem. Seems that GNU must make a better ld. However, using HP:s ld & as can also cause trouble, Bob writes: I compiled gcc and got it to work occasionally under 7.0, but it intermittently dies when compiling. It gripes about unexpected EOF on some assembler source file in /tmp/. If I re-run the same job (by typing "make" again, usually), it usually succeeds. I'm not sure, but I think that gcc tries to be fast by invoking the assembler before it's finished writing the assembler source file. If this is true, then the HP-UX assembler must be too fast for gcc. I didn't spend a lot of time on it, though, and abandoned it soon after. (I needed an ANSI compiler to test something out. Once the test was over, I didn't need the compiler.) I haven't tested this, but the info can be useful to those using HP stuff. Some minor details: The subdirectory binutils/hp-include/sys must be removed on HP-UX 7.0. The symbols _etext, _edata and _end requires an extra underscore (i.e. __etext, __edata, __end) under HP-UX. If you get a 'Undefined symbol' warning about these, just prepend a _. The stdio.h in libg++ want's 'char' in the iobuf struct. HP:s has 'unsigned char'. This could be a source for trouble, but I haven't noticed any yet. Changing to 'unsigned char' will cause LOTS of errors when compiling libg++. It requires lots of changes to overcome this. Thus, I haven't done it. Compiling libg++ itself produces heaps of warnings. Just ignore these. All these info has been posted to the GNU people. Hopefully it will be easier to build gcc and g++ in future releases. Jan D.