On Mon, 18 Aug 2003, Norman Gray wrote:
> > Case sensitivity. The partitions provide case sensitivity in a
> > limited sense, files with the same sequence of characters are
> > the same file, even though they look different (i.e. WCS.h is the
> > same file as wcs.h). Skycat is full of these and we cannot do
>
> Yes, HFS+ is `case preserving but not case sensitive', and this is (or
> was) deemed to be a feature. UFS (ie, Unix FS) is a traditional unix
> filesystem (case-preserving and -sensitive) also supported by OS X.
> As of 10.2 (the current version; 10.3, aka Panther, is coming this
> year) I understand that OS X can boot and root off of a UFS disk, and
> I get the impression that Apple are starting to favour UFS over HFS+
> (it's a bit like HDS: full of nifty things which no-one else can see
> the advantage of). I don't know if this means that new systems will
> come preformatted as HFS+ or UFS.
>
> Apple have a guide on porting to OS X, at [1]
Hi Norman,
thanks, did wonder whether a UFS partition was possible, but it wasn't my
machine so the option wasn't available...
> > Compiler/linker issues. Used gcc 3.1, which is a bit early (3.2 is
>
> I don't know the details of the compiler version story. I think Apple
> are reasonably happy to be up-to-date on these, without being
> bleeding-edge, so I'd guess this'd improve quietly in the next
> release. I'm sure I read somewhere, though I can't now find it, that
> they have no urgent plans to include g77 in the devtools (can't think
> why).
If this was my machine I would have tried to downgrade to 2.95.2. This
would have probably helped with some issues.
> > Ranlib. Worth a section of it's own. When you copy or move
> > a libxxx.a file you need to re-run ranlib. Caused major problems
> > in GKS which incrementally builds the .a library and moves in
> > around. Also you can not put anything but .o files in a library
> > and expect ranlib to work. Some packages mix in plain files (by
> > accident).
>
> Ah yes. OS X uses a `two-level namespace', which is presumably clever,
> but is definitely confusing. There's a flag to flatten it, which you may
> have found. For what it's worth, libtool works OK, with Apple-contributed
> patches.
>
> You probably have noticed that the man pages are badly out-of-date in
> some places. In 10.0 they were just the old NextStep/OpenStep man
> pages and bore only a loose relation to OS X; I understand this is
> being improved, but somewhat slowly.
Didn't spot this two-level namespace stuff on quickly passing. It may be
the issue with below (where you need to visit the filesystem to resolve
any relative parts, must be this walk that cause the break), but you're
right switching to libtool did help.
> > GAIA: doesn't seem to track down relative softlinks (crash in contour
>
> That's odd -- I haven't seen any problems with links before.
>
> > sockaddr_in etc. (usual problems with really new UNIX).
>
> Or indeed old ones. Linux and SunOS/Solaris are to some extent BSD/SYSV
> hybrids (heaven knows what DUX is), whereas OS X is directly descended
> from 4.4BSD, via FreeBSD, with a few differences described in [2].
>
> One of these differences, incidentally, is that ``Mac OS X does not
> support memory-mapped devices through the mmap() function. (Graphic device
> support and other subsystems provide similar functionality, but using
> different APIs.) In Mac OS X, this interface should be done through user
> clients. See the Apple I/O Kit documents for additional information.''
> This, and the deprecation of sbrk, are probably because OS X is sitting
> on top of Mach, so doesn't do its own memory management.
I'm hoping that sounds worse than it is, and mmap() for files is OK?
Cheers,
Peter.
|