Openstep

Openstep

[Dave Love]

ISTR talk about an Openstep port at some stage (there's certainly been
an enquiry or two about g77 on it).  Is this of interest in that
regard?  [Sorry if Toon's already acted on it -- mail here somewhat
disrupted.]

------- Start of forwarded message -------
From: dirk@kalium.physik.TU-Berlin.DE (Dirk Schwarzhans)
Newsgroups: comp.sys.next.software,comp.lang.fortran
Subject: Re: Fortran on Rhapsody?
Date: 20 Jan 1998 14:26:22 GMT
Organization: Technical University Berlin, Germany
Message-ID: <6a2c6e$l9b$1@mamenchi.zrz.TU-Berlin.DE>
References: <884603095.933953540@dejanews.com> <rzq4t366eub.fsf@djlvig.dl.ac.uk>   <69t5vg$8iu$1@news2.xs4all.nl> <6a20si$jsh$1@msunews.cl.msu.edu>

Hello,

On 01/20/98, spammers@ruin.the.internet.channelu.com wrote:
>I may actually try to get either g77, or f2c working on Rhapsody..
>If anyone else has actually tried, or is trying I'd like to hear
>from them.  I thought about trying it on Openstep 4.2 also, but it
>appears I'll have to try to upgrade gcc from 2.7.2.1 on 4.2 to a
>gcc that has g77, or try to see what version of f2c might work..
>I'm not sure how things will cooperate in 4.2

There is a ready to use package for OPENSTEP 4.2 which contains the 
g77 FORTRAN compiler. It can be found at 
ftp://ftp.cs.tu-berlin.de/pub/NeXT/developer/languages/gcc.2.7.2.3.2.I
.b.tar.gz

It tried our fit program for molecular potential functions and it 
seems to run slightly faster than the same code compiled with the 
absoft compiler (optimization turned on for both compilers).

Hope this helps,

Dirk
-- 

------------------------------------------------------------------
Dirk Schwarzhans
Email: dirk@kalium.physik.TU-Berlin.DE (MIME and NeXTMail welcome)
WWW: http://pl.physik.TU-Berlin.DE/DZ/Dirk/
------------------------------------------------------------------

------- End of forwarded message -------

Re: Openstep

[Timothy J. Wood]

[-- Attachment #1: Type: text/plain, Size: 3082 bytes --]

  I had a version of egcs-971225 up and running under OpenStep/4.2 Mach (i386-next-nextstep4), but through some random change I seem to have broken my local copy.  The changes required to get a naive port (about all I'm able to do considering how much I know about gcc/egcs) were pretty minimal.  Included below is a message I sent to another person that asked (on one of the OpenStep/Rhapsody lists if I remember correctly).

I haven't had time to get back to working on this yet, but feel free to take up the torch :)

The changes necessary to get this working on Rhapsody might be more substantial since Rhapsody has a standard BSD4.4 include structure instead of the non-standard tree that NeXT previously had.  You *might* be able to do a really quick and dirty port by just using {i386,ppc}-next-nextstep4 as your configuration (heck, configure might even figure it out).

The biggest piece of work left to do is to make gcc do the correct PIC stuff for the latest linker (pretty much the same on OpenStep/4.2 and Rhapsody DR1 Intel -- I haven't looked at what they do on PPC).  The current approach (static references) would make the linker complain about relocation entries in non-writable sections (meaning that you'll make pages writable at dylinker time and end up using more VM).  I doesn't complain since I set up the specs file to call the linker with args to make it shut up about these warnings ... hopefully a temporary state of affairs.

There may be some large number of errors in the regression tests.  I was able to get dejagnu up and limping along, but I'm not convinced that I ever got any valid results out of it, mostly since I don't really know how to use it correctly. :)

Basic hand-written tests of C and ObjC work(ed).  In particular, I could subclass NSObject (which is in a different framework) and stuff didn't crash.  I didn't test C++ or Fortran at all.  I don't recall the C++ libraries failing to build, so that might be a very minimal test.

-tim




X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.0b5)
From: Timothy J. Wood <tjw@omnigroup.com>
Date: Mon, 12 Jan 98 10:35:55 -0800
To: gvandyk@icon.co.za
Subject: Re: egcs, gcc, OPENSTEP, and Apple
Reply-To: Timothy J. Wood <tjw@omnigroup.com>
X-Url:  ` http://www.omnigroup.com/People/bungi

Strangely, I can't seem to get it to work again, but I don't see how I could have messed it up.  A bunch of weird stuff is getting inserted into the middle of gcc/Makefile.  The stage1 still seems to build, but partway through stage2, I get a gnumake error.  Perhaps this is some local configuration detail that has changed and this won't effect you.  I can't guarantee that these patches will work though :)

There are three files that have changed.  Here are the diffs:

egcs-971225-nextstep-diffs


  Here is the log of changes I made while building stuff up.  If you get to the part where you are ready to run the regression tests, let me know if you what the changes I made to the egcs snapshot of dejagnu (they are pretty minor and described in my log file).

egcs-i386-next-nextstep4-notes

-tim
 

[-- Attachment #2: egcs-971225-nextstep-diffs --]
[-- Type: text/x-diff, Size: 4415 bytes --]

*** egcs-971225/gcc/cccp.c      Sun Jan 11 22:17:11 1998
--- dist/egcs-971225/gcc/cccp.c Mon Dec  8 23:55:17 1997
***************
*** 358,369 ****
  
  /* Nonzero means warn if #import is used.  */
  
- #ifdef NeXT
- /* NEXTSTEP uses #import in all of the system headers.  Generating a warning each time is not an option. */
- static int warn_import = 0;
- #else
  static int warn_import = 1;
- #endif
  
  /* Nonzero means turn warnings into errors.  */
  
--- 358,364 ----
*** egcs-971225/gcc/cpplib.c    Sun Jan 11 22:17:45 1998
--- dist/egcs-971225/gcc/cpplib.c       Sat Dec  6 16:28:14 1997
***************
*** 811,822 ****
    opts->pedantic_errors = 0;
    opts->inhibit_warnings = 0;
    opts->warn_comments = 0;
- #ifdef NeXT
- /* NEXTSTEP uses #import in all of the system headers.  Generating a warning each time is not an option. */
-   opts->warn_import = 0;
- #else
    opts->warn_import = 1;
- #endif
    opts->warnings_are_errors = 0;
  }
  
--- 811,817 ----
*** egcs-971225/gcc/config/nextstep.h   Mon Jan 12 10:11:01 1998
--- dist/egcs-971225/gcc/config/nextstep.h      Sat Dec  6 09:24:06 1997
***************
*** 104,120 ****
  
  /* These compiler options take n arguments.  */
  
- #warning TJW: This does not work quite right since we do not included all of the contents of the NS4.2 specs file in the specs file generated for the stage1 build.  So, I am guessing that this is not defined for the stage two build.
- 
- #if NS_TARGET_MAJOR >= 4
-    /* This is an incomplete list of the new args that the linker accepts */
-    /* TJW: Need to get to integrate the -F switch for adding framework directories.  Could probably just crib the code from the NeXT version of gcc. */
- #define NS4_WORD_SWITCH_ARG(STR) \
-    !strcmp (STR, "framework") ? 1 :
- #else
- #define NS4_WORD_SWITCH_ARG(STR)
- #endif
- 
  #undef        WORD_SWITCH_TAKES_ARG
  #define WORD_SWITCH_TAKES_ARG(STR)            \
    (DEFAULT_WORD_SWITCH_TAKES_ARG (STR) ? 1 :  \
--- 104,109 ----
***************
*** 132,138 ****
     !strcmp (STR, "siff-warning") ? 1 :                \
     !strcmp (STR, "arch") ? 1 :                        \
     !strcmp (STR, "pagezero_size") ? 1 :               \
-    NS4_WORD_SWITCH_ARG(STR)                   \
     0)
  
  #undef        WORD_SWITCH
--- 121,126 ----
***************
*** 168,198 ****
  /* Machine dependent libraries.  */
  
  #undef        LIB_SPEC
- #if NS_TARGET_MAJOR >= 4
- #define LIB_SPEC "%{!posix*:-lcc_dynamic -framework System} %{posix*:-lposix}"
- #else
  #define LIB_SPEC "%{!posix*:-lsys_s} %{posix*:-lposix}"
- #endif
  
! /* We specify crt[01].o as -lcrt[01].o so that ld will search the library path. */
  
  #undef        STARTFILE_SPEC
- #if NS_TARGET_MAJOR >= 4
-     /* TJW: I did not touch the profiling part of this */
-     /* TJW: The '-read_only_relocs suppress' disables warnings generated by the NeXT linker
-        due to the fact that egcs is putting relocation entries in the text segment
-        rather than (I presume) the data segment.  Someone should fix this when they
-        get a chance.  This doesn't break anything that I know of, but just makes the
-        program take up more swap (since it has to make those pages writable).
-      */
- #define STARTFILE_SPEC  \
-     "%{!posix*:%{pg:-read_only_relocs suppress -dynamic -lgcrt1.o}%{!pg: \
-      %{p:%e-p profiling is no longer supported.  Use -pg instead.} \
-      %{!p:-read_only_relocs suppress -dynamic -lcrt1.o}}}\
-      %{posix*:%{pg:-lgposixcrt0.o}%{!pg: \
-      %{p:%e-p profiling is no longer supported.  Use -pg instead.} \
-      %{!p:-lposixcrt0.o}}}"
- #else
  #define STARTFILE_SPEC  \
      "%{!posix*:%{pg:-lgcrt0.o}%{!pg: \
       %{p:%e-p profiling is no longer supported.  Use -pg instead.} \
--- 156,166 ----
  /* Machine dependent libraries.  */
  
  #undef        LIB_SPEC
  #define LIB_SPEC "%{!posix*:-lsys_s} %{posix*:-lposix}"
  
! /* We specify crt0.o as -lcrt0.o so that ld will search the library path. */
  
  #undef        STARTFILE_SPEC
  #define STARTFILE_SPEC  \
      "%{!posix*:%{pg:-lgcrt0.o}%{!pg: \
       %{p:%e-p profiling is no longer supported.  Use -pg instead.} \
***************
*** 200,206 ****
       %{posix*:%{pg:-lgposixcrt0.o}%{!pg: \
       %{p:%e-p profiling is no longer supported.  Use -pg instead.} \
       %{!p:-lposixcrt0.o}}}"
- #endif
  
  /* Allow #sscs (but don't do anything). */
  
--- 168,173 ----

[-- Attachment #3: egcs-i386-next-nextstep4-notes --]
[-- Type: text/x-c, Size: 6285 bytes --]

Source  in /Cache/bungi/egcs-971225
Objects in /Cache/bungi/egcs-objdir-971225
configured with:

CC="/bin/cc -traditional-cpp" ../egcs-971225/configure --prefix=/Cache/bungi/egcs-install-971225 --without-gnu-as --without-gnu-ld

Configuring for a i386-next-nextstep4 host.
Created "Makefile" in /Cache/bungi/egcs-objdir-971225
Links are now set up to build a native compiler for i386-next-nextstep4

  The CC definitiion is needed to ensure that -traditional-cpp is sent to the system compiler.
  The NeXT supplied port of gcc 2.7.2 uses a different version of cpp that supports precompiled headers.  Unfortunately, this program has many bugs, including the fact that it doesn't understand '__attribute__'.  Fortunately, it can be turned off and the normal version used with '-traditional-cpp'.  This seems to be addressed somewhere since the generated gcc/Makefile contains the lines:

    ####host overrides
    
    # Make assignments for compiling on NeXT with their compiler version.
    CC=cc -traditional-cpp
    OLDCC=cc -traditional-cpp

  But -traditional-cpp is never issued when compiling .c files.  This causes cccp.c to fail and gcc/config/i386/i386.c to fail.
  Reconfiguring with CC="/bin/cc -traditional-cpp" seems to fix the problem, but it shouldn't be necessary.

  After configuring, just do a 'gnumake bootstrap'



  Description of changes:

------------

  Under NEXTSTEP and Rhapsody, it is totally inappropriate to warn on usage of '#import'.  I've modified cccp.c and libccp.c to not do this if NeXT is defined.

------------

  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" and then "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

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

------------

  I was able to add a linker flag (undocumented, I think) to the specs stuff to suppress the warnings about the static relocation entries.

------------

  At this point, egcs builds.  So, I downloaded dejagnu and configured with:

/Cache/bungi/dejagnu-971028          Source
/Cache/bungi/dejagnu-objdir-971028   Objects
/Cache/bungi/dejagnu-install-971028  Install


../dejagnu-971028/configure --prefix=/Cache/bungi/dejagnu-install-971028
Configuring for a i386-next-nextstep4 host.
Created "Makefile" in /Cache/bungi/dejagnu-objdir-971028
../../../dejagnu-971028/tcl/unix/configure: uname: not found
configure: warning: Can't find Tk configuration definitions
configure: warning: Can't find Itcl private headers
configure: warning: Can't find Tk private headers
configure: warning: No X based programs will be built

------------

  tclUnixFCmd.c uses some POSIX defines that are not available by default on NEXTSTEP.  Added the following to the top of this file hacked around the problem.  A better solution is needed.

#ifdef _NEXT_SOURCE
#define _POSIX_SOURCE
#endif

------------

  The tcl packaged with the dejagnu snapshot does not contain all of the source that the normal dejagnu tcl package contains.  In particular, it was missing tclLoadNext.c.  I copied this from dejagnu-1.3.

  Additionally, the rule necessary to cause this file to get built was missing (even though the Makefile contained code to use the output).  This was easily fixed by patching in a hack to the Makefile by hand.

------------

  The generated Makefile in the tcl directory was trying to add '-lc' which is not correct for NEXTSTEP.  Remove the reference by hand.

------------

  The tclLoadNext.c didn't have a definition of TclGuessPackageName() although other load files do.  Copied the definition from tclLoadDld.c (just returns 0 to indicate that it couldn't guess).

------------

  NEXTSTEP doesn't have a mkfifo (at least w/o -lposix which doesn't work real well).  Changed tclUnixFCmd.c to just return an error from TclpCopyFile() if the input is a FIFO.

------------

  After building and installing the patched dejagnu in /Cache/bungi/dejagnu-install-971028, I ran the tests with:

  PATH=$PATH:/Cache/bungi/dejagnu-install-971028/bin gnumake -k check