Peter,
On Mon, 18 Aug 2003, Peter W. Draper wrote:
> If this was my machine I would have tried to downgrade to 2.95.2. This
> would have probably helped with some issues.
I have the impression that gcc 3.x has suddenly got a lot pickier about
syntax -- to the extent that it even occasionally picks up on things
that even DUX cxx and Solaris CC haven't complained about.
However, in [1]
If you run into a problem that looks like a compiler bug, the command
sudo gcc_select 2 will change the default compiler to gcc 2.95.2. You
can change it back at any time by typing sudo gcc_select 3. This
should be treated as a last resort, though. If possible, you should
try to get gcc 3 to compile your application by specifying different
compiler flags.
> > > 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.
The two-level namespace stuff is to do with linking against dynamic
libraries: the linker knows what library a given symbol is to be
resolved in, rather than searching all the available libraries for it[1].
I'm not sure how this is relevant to having to look at the filesystem
or not (I can't see how there would be any connection). At any rate,
they say that you'll practically always have to use -flat_namespace.
Just by the way, note that OS X `aliases' are not the same as symlinks
(they're much `stickier', because they make the link using the filesystem
path _and/or_ the inode-like object on HFS+) -- I don't imagine
any of the devtools are installed with those, but it's worth knowing
that they probably shouldn't be.
> > 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?
I read it carelessly first time. mmap(2) for files does indeed seem
to be perfectly OK[2]
Norman
[1] http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_3.html
[2] http://developer.apple.com/documentation/Performance/Conceptual/Performance/FilesNetworksThreads/Reading_Lar_ile_Mapping.html
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [log in to unmask]
