[9fans] plan9ports & macos 10.4 don't like each othere.

[9fans] plan9ports & macos 10.4 don't like each othere.

[Ronald G Minnich]

so, anybody out there done plan9 ports for macos 10.4.3? I loaded up 
xcode 2.1, and the compile gets in trouble very early in the game: 
ushort is undefined. This points to larger problems, I was wondering 
just how large before I jumped in to the shallow end of the pool.

ron

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Ben Huntsman]

There's an option in XCode that allows you to choose to use GCC4 or  
GCC3.  Lots of stuff doesn't build right on Mac OS X 10.4 with GCC4  
yet...
If you think that will help, I'll dig through XCode and find where  
the option is, because I forget off the top of my head...

-Ben

On Nov 9, 2005, at 12:19 PM, Ronald G Minnich wrote:

> so, anybody out there done plan9 ports for macos 10.4.3? I loaded  
> up xcode 2.1, and the compile gets in trouble very early in the  
> game: ushort is undefined. This points to larger problems, I was  
> wondering just how large before I jumped in to the shallow end of  
> the pool.
>
> ron

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Russ Cox]

> so, anybody out there done plan9 ports for macos 10.4.3? I loaded up
> xcode 2.1, and the compile gets in trouble very early in the game:
> ushort is undefined. This points to larger problems, I was wondering
> just how large before I jumped in to the shallow end of the pool.

I have a 10.4 iBook working fine, but it might not be 10.4.3 nor Xcode 2.1.
I know a handful of people who run it on Macs every day.

Russ

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Matt Sottile]

Using 10.4.3, gcc4, and just the plain old apple XCode install and  
tools, I have no trouble compiling it.

-m

On Nov 9, 2005, at 1:30 PM, Russ Cox wrote:

>> so, anybody out there done plan9 ports for macos 10.4.3? I loaded up
>> xcode 2.1, and the compile gets in trouble very early in the game:
>> ushort is undefined. This points to larger problems, I was wondering
>> just how large before I jumped in to the shallow end of the pool.
>
> I have a 10.4 iBook working fine, but it might not be 10.4.3 nor  
> Xcode 2.1.
> I know a handful of people who run it on Macs every day.
>
> Russ

---
Matthew Sottile (matt@lanl.gov)
Advanced Computing Laboratory (CCS-1)
Los Alamos National Laboratory
Los Alamos, NM 87545
Phone: (505)665-6057
Web: http://ddma.lanl.gov/~matt/

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Ronald G Minnich]

Matt Sottile wrote:
> Using 10.4.3, gcc4, and just the plain old apple XCode install and  
> tools, I have no trouble compiling it.

it works for me as long as I'm not root.

woo hoo.

ron

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Jeff Sickel]

On Nov 9, 2005, at 2:52 PM, Ronald G Minnich wrote:
>
> it works for me as long as I'm not root.


just build it w/ Russ' INSTALL script.  gcc4 works fine, and once mk  
is built, the rest is a piece of cake.

jas

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Ronald G Minnich]

Jeff Sickel wrote:

> just build it w/ Russ' INSTALL script.  gcc4 works fine, and once mk  is 
> built, the rest is a piece of cake.

that much I know since I build it about once a day on all sorts of 
things. As I said, I can build it fine, as long as I'm not root.

I don't know what the issue is, have not had time to look at it.

ron

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Jeff Sickel]

On Nov 9, 2005, at 9:46 PM, Ronald G Minnich wrote:
>
> I don't know what the issue is, have not had time to look at it.

Russ posted a recent update to libthread and there are updates to bin/ 
9l and src/cmd/auxstats/mkfile that I hope make it in sometime in the  
near future (only needed for auxstats right now, and I respect Russ'  
busy schedule).

This actually leads to the question: since Apple's announced the x86  
support for Mac OS X, would it be beneficial to modify the mkfile's  
for the Darwin port to support the MachO multi-binary options by  
making 9c & 9l deal with the Darwin sources in a similar way as the  
Plan 9 compiler does?  Though MachO supports 'fat' binaries after the  
linker has handled them, I think it would be better to handle the  
object files in the same manner as the Plan 9 compiler and save them  
as .[v851ok0q2t6] only to let the linker squish them together if  
needed (still allowing for fully separate libraries and executables  
for each Darwin platform if needed).

Would anyone mind if I made the required changes to 9c, 9l and any  
supporting mkfiles?

jas

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Russ Cox]

> Russ posted a recent update to libthread and there are updates to bin/
> 9l and src/cmd/auxstats/mkfile that I hope make it in sometime in the
> near future (only needed for auxstats right now, and I respect Russ'
> busy schedule).

Please don't assume that I've properly queued things
that I don't respond about.  I completely missed the
mkfile change in your mail.  I think the other changes
(in 9l) have been applied for a few weeks.  If there are
any changes you think I'm still missing, please resend them.

> This actually leads to the question: since Apple's announced the x86
> support for Mac OS X, would it be beneficial to modify the mkfile's
> for the Darwin port to support the MachO multi-binary options by
> making 9c & 9l deal with the Darwin sources in a similar way as the
> Plan 9 compiler does?  Though MachO supports 'fat' binaries after the
> linker has handled them, I think it would be better to handle the
> object files in the same manner as the Plan 9 compiler and save them
> as .[v851ok0q2t6] only to let the linker squish them together if
> needed (still allowing for fully separate libraries and executables
> for each Darwin platform if needed).
>
> Would anyone mind if I made the required changes to 9c, 9l and any
> supporting mkfiles?

I would mind.  It's a pain that .o is the same suffix everywhere,
but it's a fact of life on Unix.  If the code got ported to Windows
using MSVC (looking less likely now that I know about mingw),
I would fully expect to use .obj.

Plan 9 from User Space walks a fine line between avoiding
the ugliness of Unix and trying to coexist peacefully with it.
I think it would be too radical a change if you ran 9c and got
a .8 file out, especially given that the .8 would actually *be* a .o.
It would be a different story if it were a Plan 9 .8 file.  9l generates
a.out for the same reason.  It's difficult to articulate exactly
where the line is in general, except that I built an earlier system
that tried to be much more like Plan 9 (it had all the system calls
and a user-level kernel that all the "Plan 9" applications talked to).
It succeeded at being more like Plan 9 but it failed at being
useful.  It felt like I had built another world on top of the host
system (Windows in this case).  The current tools feel more
integrated into the host system, and I like that a lot.

Also, using .8 and .q instead of .o still wouldn't be completely specific:
as I move between FreeBSD and Linux I frequently find myself
staring at .o files and having no idea which system they're
compiled for.  mk clean; mk.

Russ

Re: [9fans] plan9ports & macos 10.4 don't like each othere.

[Jeff Sickel]

On Nov 9, 2005, at 11:53 PM, Russ Cox wrote:
>
> Please don't assume that I've properly queued things
> that I don't respond about.  I completely missed the
> mkfile change in your mail.  I think the other changes
> (in 9l) have been applied for a few weeks.  If there are
> any changes you think I'm still missing, please resend them.

Sorry about the assumption bit on my part.  Sometimes juggling so  
many different source trees gets to be confusing, though I'll admit  
that after seeing the cleanup of the mkfiles and changes in the  
plan9port of a period of time, I've been convinced to move more  
projects into a similar vein.

>> Would anyone mind if I made the required changes to 9c, 9l and any
>> supporting mkfiles?
>
> I would mind.  It's a pain that .o is the same suffix everywhere,
> but it's a fact of life on Unix.  If the code got ported to Windows
> using MSVC (looking less likely now that I know about mingw),
> I would fully expect to use .obj.

Trouble is.. and this comes from doing many multi-architecture ports  
on NEXTSTEP (68040, x86, HPPA, Sparc) to PowerPC and subsequent uses  
of macho formats for Darwin, I've found that on the few OSs where you  
actually get to deal with various hardware, having a build system  
that's somewhat sane and tells you which object files go with what  
can be a fantastic thing (a big thank you to the architects of Plan 9).

> Plan 9 from User Space walks a fine line between avoiding
> the ugliness of Unix and trying to coexist peacefully with it.
> I think it would be too radical a change if you ran 9c and got
> a .8 file out, especially given that the .8 would actually *be* a .o.
> It would be a different story if it were a Plan 9 .8 file.  9l  
> generates
> a.out for the same reason.  It's difficult to articulate exactly
> where the line is in general, except that I built an earlier system
> that tried to be much more like Plan 9 (it had all the system calls
> and a user-level kernel that all the "Plan 9" applications talked to).
> It succeeded at being more like Plan 9 but it failed at being
> useful.  It felt like I had built another world on top of the host
> system (Windows in this case).  The current tools feel more
> integrated into the host system, and I like that a lot.

The current Xcode build environment philosophy is an unfortunate  
bastardization of the old ProjectBuilder Makefiles melded through a  
brief period of Jam and finally into their hell-born XML based build  
system that ends up creating awful subdirectories for each target  
object file and only at the end linking them all together in a 'fat'  
binary (US Patent No. 5,432,937) that is usable on 'any' current Mac  
OS X architecture as long as it includes your natively linked symbols  
and hasn't been run through lipo (gotta trim the fat somehow).  But  
since very few people build 68040, HPPA, or Sparc versions of code w/  
Apple's version of gcc, it isn't too much of a problem.

The current Plan 9, plan9ports and Inferno build environments offer  
what I've come to consider as a much more sane system for  
bootstrapping on each host/terminal.  I'd just like to see a little  
more of that carry over into other environments as much as possible.

> Also, using .8 and .q instead of .o still wouldn't be completely  
> specific:
> as I move between FreeBSD and Linux I frequently find myself
> staring at .o files and having no idea which system they're
> compiled for.  mk clean; mk.

Agreed.  Though as more of the BSD and Linux distributions become  
multi-architecture capable, it will be more and more of a mess to  
wade through the various output their separate versions of gcc, gas,  
and gnu ld end up producing.

I just think that the plan9port example is a good start on cleaning  
up that kind of build process mess.

jas