> 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
