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

[Russ Cox <rsc@swtch.com>]

> 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