From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Thu, 10 Nov 2005 00:53:54 -0500 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] plan9ports & macos 10.4 don't like each othere. In-Reply-To: <98C8D026-907D-4DAB-8A12-05C964625FA4@corpus-callosum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <437259C9.5010003@lanl.gov> <0E7FF0EA-61C0-4806-9533-070EAFAAEF30@lanl.gov> <43726187.8000806@lanl.gov> <4372C2A2.1090802@lanl.gov> <98C8D026-907D-4DAB-8A12-05C964625FA4@corpus-callosum.com> Topicbox-Message-UUID: aa79db36-ead0-11e9-9d60-3106f5b1d025 > 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