Re: Linux to MacOSX port effort.

[Marcus G. Daniels]

>>>>> "SC" == Scott Christley <address@hidden> writes:

SC> I've been using the stock cc and have been able to compile the
SC> misc directory and part of defobj so far.  Is there a specific
SC> reason why the new gcc needs to be used?

The parts of defobj you can't compile are likely the parts that use
nested functions.  The Apple GCC 3.1 branch handles a simple case like
this now:  

void
bappy (void (*blargh) ())
{
  blargh ();
}

int
main ()
{
  void blargh () { printf ("blargh!\n"); }

  bappy (blargh);
}

..but now more complex cases are crashing the compiler.

SC> I'm taking a slightly different approach then maybe others, I'm
SC> using Apple's ProjectBuilder instead of the GNU configure/make
SC> sequence.  I will deal with configure changes after I get a better
SC> handle what source code changes are required.

I would be concerned that compile-time flags and configuration data
would be wrong if the autoconf tests were not done.  It seems like the
easiest way to identify the right configuration details would be to
get the normal build working, and then repackage the details for
ProjectBuilder.

SC> The other issue are the two objc runtimes; I'm not sure how
SC> practical using the GNU runtime will be on OSX except for a purely
SC> X approach.  I'm still getting familiar with the guts of Swarm
SC> source code so that I can add code to use Apple's runtime.

It isn't possible to use the NeXT-like runtime with Swarm.  There are
enhancements added to the (GNU) libobjc included with Swarm that handle
the assembly and disassembly of method call frames.

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.