Peter,
On Mon, 18 Aug 2003, Peter W. Draper wrote:
> I've attached the notes I made during the compilation to this message. The
> worst problem is the lack of proper case-sensitivity of HFS and the early
> GCC 3 compiler available (this problem may of course go away, as would the
> case-sensitivity issues, if I could work out how to cross-compile for
> OSX).
I can add a little to Peter's notes, not because I believe it's a
priority to do more, but to log it in the list archive.
> 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]
> 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).
> 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.
> 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.
Norman
[1] http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/index.html
[2] http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/BSD/chapter_11_section_3.html
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
|