i386-next-nextstep: some more info

i386-next-nextstep: some more info

[Timothy J. Wood]

  I've gone back and performed a build with the latest snapshot to reproduce  
the problems I was having with egcs calling the nextstep4 linker as if it  
were the nextstep3 linker.  The details follow.

  I see that there is some stuff in gcc/config/nextstep.h that has specs  
strings.  I don't really know what these do, but I can probably guess at some  
of them (which I'm going to try now ...)

  Should I create a nextstep4.[ch] or put #ifdefs in the current  
nextstep.[ch].  Most of the stuff is going to stay the same (I hope), so I'll  
try to opt for the latter unless someone lets me know otherwise.

-tim



  The details:

  After building xgcc, 'enquire' is built with xgcc.  The program links, but  
fails on startup due to misuse of the builtin linker.

% ./xgcc -v -B./ -DIN_GCC -g -I./include enquire.o -o enquire
Reading specs from ./specs
gcc version egcs-2.91.03 971225 (gcc-2.8.0)
 ./ld -o enquire -lcrt0.o -L. enquire.o -lgcc -lsys_s -lgcc
/bin/ld: warning table of contents of library: ./libgcc.a not sorted slower  
link editing will result (use the ranlib(1) -s option)


% ./ld -v -o enquire -lcrt0.o -L. enquire.o -lgcc -lsys_s -lgcc
collect2 version egcs-2.91.03 971225 (gcc-2.8.0) (80386, BSD syntax)
/bin/ld -v -o enquire -lcrt0.o -L. enquire.o -lgcc -lsys_s -lgcc
/bin/ld: unknown flag: -v
collect2: ld returned 1 exit status

  On OpenStep/4.2 Mach, if you do:

% echo "main(){} > /tmp/foo.c
% cc -v /tmp/foo.c -o /tmp/foo

  you get:

Reading specs from /lib/i386/specs
NeXT Software, Inc. version cc-744.13, gcc version 2.7.2.1
 /lib/i386/cpp-precomp -smart -lang-c -v -arch i386 -undef -D__GNUC__=2  
-D__GNUC_MINOR__=7 -D__GNU__ -Di386 -DNeXT -Dunix -D__MACH__  
-D__LITTLE_ENDIAN__ -D__ARCHITECTURE__="i386" -D__i386__ -D__NeXT__  
-D__unix__ -D__MACH__ -D__LITTLE_ENDIAN__ -D__ARCHITECTURE__="i386" -D__i386  
-D__NeXT -D__unix -D__STDC__ -D_NEXT_SOURCE -DNX_COMPILER_RELEASE_3_0=300  
-DNX_COMPILER_RELEASE_3_1=310 -DNX_COMPILER_RELEASE_3_2=320  
-DNX_COMPILER_RELEASE_3_3=330 -DNX_CURRENT_COMPILER_RELEASE=410  
-DNS_TARGET=41 -DNS_TARGET_MAJOR=4 -DNS_TARGET_MINOR=1 -D__NEXT_CPP__  
-D__DYNAMIC__ /tmp/foo.c /usr/tmp/cc000791.i
NeXT DevKit-based CPP 4.0
 /lib/i386/cc1obj /usr/tmp/cc000791.i -arch i386 -quiet -dumpbase foo.c  
-version -dynamic -fPIC -o /usr/tmp/cc000791.s
GNU Obj-C version 2.7.2.1 (80386, BSD syntax) compiled by GNU C version 2.7.2.1.
 /lib/i386/as -arch i386 -o /usr/tmp/cc000791-foo.o /usr/tmp/cc000791.s
 /bin/ld -arch i386 -o /tmp/foo -dynamic -lcrt1.o /usr/tmp/cc000791-foo.o  
-lcc_dynamic -framework System
 /bin/objcunique /tmp/foo

  So, if I replace the egcs generated ld command with:

% /bin/ld -arch i386 -o enquire -dynamic -lcrt1.o enquire.o -lcc_dynamic  
-framework System

  I get:

/bin/ld: warning enquire.o has external relocation entries in non-writable  
section (__TEXT,__text) for symbols:
_printf
_setjmp
_fprintf
__iob
_sscanf
__flsbuf
_sprintf
_strcmp
_exit
_signal
_malloc
_longjmp

  The warnings are due the egcs generated code is using static references to  
functions in dynamic shared libraries.  This is annoying, but the executable  
works.

Re: i386-next-nextstep: some more info

[Jeffrey A Law]

  In message < 199801060012.QAA27756@ignem.omnigroup.com >you write:
  >   Should I create a nextstep4.[ch] or put #ifdefs in the current  
  > nextstep.[ch].  Most of the stuff is going to stay the same (I hope),
  > so I'll try to opt for the latter unless someone lets me know otherwise.
I suspect that you can just create nextstep4.h, have it include nextstep.h
and override a few things that you need to do differently.

jeff