🚀 go-pugleaf

This is what I did to compile GCC-2.2.2 under NeXTSTEP 3.0.
You may adopt a different approach.  I hope this helps.

===========================================================================
1.  -traditional-cpp
---------------------------------------------------------------------------

For now, I just want you to know about this.  Don't perform this step
yet, because you'll do it at the right time as part of (4. THE CURE).

  Add -traditional-cpp to CFLAGS in Makefile.  Do this *after*
    % configure --target=next
  since Makefile is generated (i.e., can overwrite your changes).

===========================================================================
2.  longlong.h
---------------------------------------------------------------------------
Edit longlong.h.

  Rms says this is the fault of NeXT's cpp-precomp, i.e., GCC cpp
  handles this fine.  I don't agree cpp-precomp is being unreasonable;
  GCC may be smart, but most compilers don't like embedded newlines in
  strings.

Symptom:

In file included from ./libgcc2.c:73:
./longlong.h:359: unterminated string or character constant
./longlong.h:368: unterminated string or character constant
*** Exit 1
Stop.

The changes I made:

*** longlong.h~	Wed Jun  3 17:51:17 1992
--- longlong.h	Sat Sep 26 23:59:53 1992
***************
*** 356,362 ****
  
  #if defined (__mc68000__)
  #define add_ssaaaa(sh, sl, ah, al, bh, bl) \
!   __asm__ ("add%.l %5,%1
  	addx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\
--- 356,362 ----
  
  #if defined (__mc68000__)
  #define add_ssaaaa(sh, sl, ah, al, bh, bl) \
!   __asm__ ("add%.l %5,%1\n\
  	addx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\
***************
*** 365,371 ****
  	     "%1" ((unsigned long int)(al)),				\
  	     "g" ((unsigned long int)(bl)))
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
!   __asm__ ("sub%.l %5,%1
  	subx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\
--- 365,371 ----
  	     "%1" ((unsigned long int)(al)),				\
  	     "g" ((unsigned long int)(bl)))
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
!   __asm__ ("sub%.l %5,%1\n\
  	subx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\

===========================================================================
3.  Two problems since upgrading to NeXTSTEP 3.0:
    moved-header-files, multiprocessing-includes-that-break-gcc
---------------------------------------------------------------------------
    These problems will go away when NeXT integrates their changes
    into GNU GCC.

    If you don't feel like reading the tedious history in this section,
    skip ahead to (4. THE CURE).

Symptom:
./libgcc2.c:912: stdio.h: No such file or directory

Let me tell you about techniques you should not bother trying.
Below, the patten is, "don't try (A) because (B)."
The reason not to try them is, basically, they turn into desperate hacks.

(1A) Adding "-I/usr/include/ansi -I/usr/include/bsd"
     to INCLUDES in Makefile.
(1B) GCC-2.2.2's cpp doesn't know about NeXT's new technique for
     compiling under multiple processors,
     namely, cpp doesn't like "#include ARCH_INCLUDE(ansi/, stddef.h)",
     and you'll get errors that look like this:
	 _eprintf
	 In file included from /usr/include/ansi/stddef.h:4,
	   from /usr/include/ansi/stdio.h:17,
	   from ./libgcc2.c:912:
	   /usr/include/ansi/machine/stddef.h:11:
	     `#include' expects "fname" or <fname>

(2A) Trying to use NeXT's `cc' (driver) and `cpp-precomp' (preprocessor),
     via symbolic link, while using GNU's cc1.
       mv gcc{,-later}; ln -s /bin/cc gcc
       mv cpp{,-later}; ln -s /lib/cpp-precomp cpp
(2B) Gcc and cpp are merely recreated by the Makefile.
     One becomes this silly at 2 a.m.

(3A) Trying to COPY NeXT's cc and cpp-precomp, in an effort to outmaneuver
     the Makefile (another caffeine-induced abortion).
       cp /bin/cc gcc; cp /lib/cpp-precomp cpp
(3B) Conflicts between GNU and NeXT headers.  For example:
       _eprintf ...
       In file included
         from /NextDeveloper/Headers/ansi/machine/stddef.h:11,
         from /NextDeveloper/Headers/ansi/stddef.h:4,
         from /NextDeveloper/Headers/ansi/stdio.h:17,
         from /usr/tmp/cc001938.cpp:912:
           /NextDeveloper/Headers/ansi/m68k/stddef.h:8:
           redefinition of `ptrdiff_t'
       ./gstddef.h:45: `ptrdiff_t' previously declared here
       /NextDeveloper/Headers/ansi/m68k/stddef.h:15:
         conflicting types for `wchar_t'
       ./gstddef.h:120: previous declaration of `wchar_t'

(4A) Copying "struct _iobuf" directly into libgcc2.c, so you don't
     need stdio.h.  (Readers may be on the verge of vomiting.)
     My reasoning at the time, given (3B):
       "I've decided the GNU gstddef.h takes priority, and I should
       compile with the GNU tools, since that's what the Makefile
       intends for libgcc.a.  Only stderr is needed for the fprintf
       below.  So ``to hell'' with the rest of stdio.h and stddef.h--
       they're just getting in the way.  I can't believe I'm doing this."
(4B) GNU-2.2.2 CPP doesn't know that NeXT's header files have moved.
       ./gcc -g -traditional-cpp -B./ -DNO_SC -DNO_MEM -DNO_STDDEF \
	 -O0 -I. -c enquire.c
       enquire.c:375: stdio.h: No such file or directory
       enquire.c:386: sys/types.h: No such file or directory
       enquire.c:387: signal.h: No such file or directory
       enquire.c:388: setjmp.h: No such file or directory

I consider my choices at this point.

  a. Add path to moved header files and go back to NeXT cc and cpp
     for building libgcc.a.  To me, this violates the GCC_FOR_TARGET
     intent of the Makefile, which is to build libgcc.a with the GNU
     compiler which was just built.

  b. Try recompiling everything all over again using NeXTSTEP 2.1
     header files (-I/usr/local/lib/gcc-lib/next/2.1/include).

I choose "b".

===========================================================================
4.  THE CURE
---------------------------------------------------------------------------

ASSUMPTION:
You've already installed the GCC.MKII.pkg from the Purdue archives,
giving you GCC-2.2.2 in a directory of your choosing, and a private
copy of NeXTSTEP 2.1 header files in /usr/local/lib/gcc-lib/next/2.1.

Find a 2.1 system or image.

Grab (2.1) /usr/include/{signal,setjmp}.h, and copy them into
  /usr/local/lib/gcc-lib/next/2.1/include on this 3.0 system.

Grab (2.1) /usr/include/sys/signal.h, and copy it into
  /usr/local/lib/gcc-lib/next/2.1/include/sys on this 3.0 system.

On the local 3.0 system:
  # cd /usr/local/lib/gcc-lib/next/2.1/include
  # mkdir machine
  # cd machine
  # ln -s /NextDeveloper/Headers/bsd/m68k/signal.h .

This is a white lie.  You're linking a 3.0 header file to a position
in your private 2.1 hierarchy.

Go back to your GCC-2.2.2 development directory.

  % make distclean
  % configure --target=next

Edit Makefile.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
46c46
< CFLAGS = -g
---
> CFLAGS = -g -traditional-cpp
318c318,319
< INCLUDES = -I. -I$(srcdir) -I$(srcdir)/config
---
> INCLUDES = -I. -I$(srcdir) -I$(srcdir)/config \
> 	-I/usr/local/lib/gcc-lib/next/2.1/include
504c505,506
< 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(ALL_CPPFLAGS) $(ENQUIRE_CFLAGS) \
        -I. -c enquire.c
---
> 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(ALL_CPPFLAGS) $(ENQUIRE_CFLAGS) \
	-I. -I/usr/local/lib/gcc-lib/next/2.1/include -c enquire.c
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Ok, here you go.  This should work.

  % make LANGUAGES=c

-- 
Geoffrey S. Knauth, Marble Associates, Inc.                Member BCS-NeXT, LPF
gsk@marble.com, (617) 891-5555 work, (617) 547-5247 home   Standard Disclaimers