I finally had a chance to submit some of my recent compiles and Nitro made them available at
http://www.nextcomputers.org/NeXTfiles/Software/New_Ports/. In the first batch I submitted the following:
bash-3.2.51.N.bs.2011-12-20.tar.gz
bison-2.4.3.N.bs.2011-12-22.tar.gz
diffutils-2.8.1.N.bs.2011-12-22.tar.gz
gawk-3.1.5.N.bs.2011-12-08.tar.gz
I also submitted my GCC 3.2.3 build together with the required changes to the system headers. The GCC port supports C language only as I was not able to get the C++ libraries working yet.
gcc-3.2.3-3_C_only.N.bs.2011-12-13.tar.gz
NS33HeadersFix-1.0.NIHS.s.tar.gz
OS42HeadersFix-1.0.NIHS.s.tar.gz
Note that all of the above are in .pkg format and are compiled for m68k only with gcc-3.2.3. With the exception of OS42HeadersFix I have not tested anything on OPENSTEP or any other architectures, but I included my patches for anyone who wants to experiment. Also note that in some cases not all of the included regression tests passed - refer to the enclosed test result files.
I will be submitting a few more packages once they are ready.
Enjoy, but please beware that I provide no warranties whatsoever :twisted:
nice job! thank you and keep em coming...
regards,
michael
This raises an interesting question. With a more modern gcc, would it be possible to compile a modern Emacs for NeXT? The most recent version that I am aware of on NeXT is 19.34.
It would be nice to have an Emacs 21 or later on NeXT so we could run more modern Emacs software. Are there any other Emacs fans around here?
Quote from: "bkmoore"This raises an interesting question. With a more modern gcc, would it be possible to compile a modern Emacs for NeXT? The most recent version that I am aware of on NeXT is 19.34.
It would be nice to have an Emacs 21 or later on NeXT so we could run more modern Emacs software. Are there any other Emacs fans around here?
I have not used Emacs so I cannot answer your question, unfortunately. Perhaps someone can give it a try, which is exactly why I wanted to share my compiles with the community.
I am currently going through Perl 5.10.1 compile, making reasonable progress. After a long struggle I got miniperl working and it is now crunching through the modules.
All of this would be so much simpler if we had a better system library. I still am thinking of porting a reasonably recent glibc, but this is way beyond my skill level, I'm afraid.
T-rexky, can you help me understand what you are doing with the GCC patch? I'm trying to compile for openstep x86, but I seem to be running into a lot of issues with gcc attributes.
Hi,
The patches that I included in the m68k port are really minimal, as I'm sure you noticed. I actually built all three stages on OS42 a while ago, but never finished, since I continue obsessing over the m68k and a "purist" approach :-). The OS42 i386 attempt was a real hack, as you can gather by reading my posts here:
http://www.nextcomputers.org/forums/viewtopic.php?t=2980.I have not tried to run the build with the native OS42 compiler, so perhaps this is what's giving you trouble? You will need as minimum: (i) edited system headers (feel free to use the .pkg I supplied); (ii) Rex Dieter's most recent egcs port; (iii) updated assembler, since the OS42 assembler chokes on the assembly produced by gcc-3.2 and many modules in stage 2 and 3 will fail.
Regarding the assembler, we are really lucky since Apple is still using GNU as-1.38 baseline. I was able to glue together some of the code from Apple's cctools-622.9 with the OS42 developer sources and the resultant assembler actually works. But it is such an ugly hack that I'd not be keen to distribute it (I am a "Sunday hobby coder" and not a software developer).
Other things to watch out for is the shell (use Bash), make and other GNU tools. The baseline OPENSTEP tools are so old that many things just appear to die with them.
You may also wish to contact
oneNeXT, since he is trying to do some work on an i386 port.
My problem now is that I do not understand how the GCC c++ library and collect2 are configured and structured - I can build the library but c++ code does not link correctly... The other issue is the crtstuff.c that wants to use sections attributes, that apparently are not supported on the NeXT. I included a patch that hacked some old code into the crtstuff.c, but I have no idea if it would ultimately work. One of these days I will ask for some help on the gcc forums.
Quote from: "gregwtmtno"T-rexky, can you help me understand what you are doing with the GCC patch? I'm trying to compile for openstep x86, but I seem to be running into a lot of issues with gcc attributes.
Thanks for the prompt and thorough response!
I haven't hit the assembly stage yet, I'm still trying to get through compiling. Basically, I'm trying to use gcc-2.9.5 to build a newer gcc. I can't remember where I got the gcc I'm using, but it was on these forums somewhere. :D
I'm using as much of the gnu toolchain as I can get my hands on. I'm just running into undeclared variable errors coming from builtin-attrs.def
No problem. The egcs port that I used as a baseline is located at:
and the specific file you'd want is
egcs-i386.1.1.2.3.NI.b.tar.gz. Rex's notes and patches are a great initial start for getting 3.2.3 to work as well...
Good luck.
Quote from: "gregwtmtno"Thanks for the prompt and thorough response!
I haven't hit the assembly stage yet, I'm still trying to get through compiling. Basically, I'm trying to use gcc-2.9.5 to build a newer gcc. I can't remember where I got the gcc I'm using, but it was on these forums somewhere. :D
I'm using as much of the gnu toolchain as I can get my hands on. I'm just running into undeclared variable errors coming from builtin-attrs.def
QuoteGood luck.
Thanks. I'm going to need it. I don't think I realized the extent of the problem when I took it on. I got it to compile, but getting a working version of as might be beyond me.
Does this mean that you actually managed to get past Stage 1 compile with the egcs that I suggested?
Quote from: "gregwtmtno"Thanks. I'm going to need it. I don't think I realized the extent of the problem when I took it on. I got it to compile, but getting a working version of as might be beyond me.
Yes, that's what it means. I'm currently struggling with stage two though. I'll let you know how it goes.
The problem I'm currently facing is that the binaries compiled with the stage one binaries aren't running. They exit with "Bus Error". I think it might be a linker issue.
Great progress!
I have not experienced any bus errors... could it perhaps be the stack size? Out of curiosity are you running NS33 or OS42?
Quote from: "gregwtmtno"Yes, that's what it means. I'm currently struggling with stage two though. I'll let you know how it goes.
The problem I'm currently facing is that the binaries compiled with the stage one binaries aren't running. They exit with "Bus Error". I think it might be a linker issue.
I'm on OS42 (emulated). I won't have time to work on it for the next few days though, but I'll check into the stack size.
I wonder if your issue is related to the virtual machine? I just rebuilt C only gcc-3.2.3 on my P4 based OS42 and it finished all three stages, including a full stage2/stage3 compare... (this effectively produces a C only gcc-3.2.3 for i386 NS42).
Quote from: "gregwtmtno"I'm on OS42 (emulated). I won't have time to work on it for the next few days though, but I'll check into the stack size.
I found the root cause and the solution to your bus errors. Make sure that you are using the correct STARTFILE_SPEC, per Rex's patch for OS42:
#define STARTFILE_SPEC \
"%{!posix*:%{static:%{pg:-lgcrt0.o}} %{!static:%{pg:-lgcrt1.o}} } %{!pg: \
%{p:%e-p profiling is no longer supported. Use -pg instead.} \
%{!p:%{static:-lcrt0.o} %{!static:-lcrt1.o} }}\
%{posix*:%{pg:-lgposixcrt0.o}%{!pg: \
%{p:%e-p profiling is no longer supported. Use -pg instead.} \
%{!p:-lposixcrt0.o}}}"(In fact I recommend that you have a good look at his complete patch before diving into the compile process.)
The key here is that you must use -lgcrt1.o and the as-shipped gcc-3.2.3 nextstep.h defaults to -lgcrt0.o. I did not see any bus errors because I incorporated some of Rex's patches into the source tree before I started fiddling with the compiles. I did not need any of this on m68k NS33 as it uses -lgcrt0.o.
Also, let's move this discussion into the gcc-3.2.3 thread for better continuity...
Quote from: "gregwtmtno"I'm on OS42 (emulated). I won't have time to work on it for the next few days though, but I'll check into the stack size.