GCC 3.2.3 / 3.4.6 - almost there!

Started by t-rexky, December 01, 2011, 10:31:06 PM

Previous topic - Next topic


Trying to recompile cctools 435.4 using your patch with GCC 2.95.3. I ran into an issue whereby I had to plunk this into the headers:

#define __private_extern__ extern

Not sure how you defined that or where, but after I defined it the compile made a lot more progress.

I am now on the step where it builds libstuff, but when it runs into the libstuff/dynamic_obj subdir it runs into a neverending loop of parsing/token reading/shifting tokens. Example:

Starting parse^M
Entering state 0^M
Reading a token: Next token is 260 (SCSPEC)^M
Reducing via rule 3 (line 247),  -> @1^M
state stack now 0^M
Entering state 2^M
Next token is 260 (SCSPEC)^M
Shifting token 260 (SCSPEC), Entering state 6^M
Reducing via rule 133 (line 888), SCSPEC  -> declmods^M
state stack now 0 2^M
Entering state 30^M
Reading a token: Next token is 261 (TYPESPEC)^M
Shifting token 261 (TYPESPEC), Entering state 7^M
Reducing via rule 140 (line 923), TYPESPEC  -> typespec^M
state stack now 0 2 30^M
Entering state 78^M
Reducing via rule 129 (line 869),  -> reserved_declspecs^M
state stack now 0 2 30 78^M
Entering state 197^M

Any suggestions? I left it for hours and hours and it just kept rolling with this process.



Please note that I compiled the cctools package with a modified (hacked) OS 4.2 gcc compiler.  Just like with the subsequent Apple versions of the gcc compilers it has numerous customizations and modifications.  Compiling with 'stock' gcc is almost guaranteed to cause issues, such as with the private extern which is a NeXT / Apple special used during linking.  It's like a local-global symbol: global to all the linked modules but local to the final linked object so it does not clash with the real globals in the libraries...

I don't remember if I posted the hacked gcc binary packages and source, but I can make it available if required.  Just don't use it for objc because it will fail miserably, but plain C works well.  I had to do a circus to make it all work since there is a circular reference: the OS 4.2 gcc requires the new cctools to compile and you require the OS 4.2 gcc to compile the cctools.  I solved that by compiling the minimal required cctools binaries for NS on OS, moving them over to my NS box and then building the hacked OS 4.2 compiler on NS.  I finally rebuilt the cctools on NS with that hacked compiler.


Thanks for the notes on this, I'm attempting to use the binary package that was uploaded to "New_Ports" in the files area here.  I'm also installing the header fix packages that are in that same folder.

Specifically I'm looking at a gcc->fltk->dillo buildchain.