Re: Patches for various crashers
On Wed, 3 Oct 2001, Christoph Pfisterer wrote:
> > > Unfortunately, Darwin is not a very friendly place to live in. I had
> >> to do some "bad hacks" to compensate for breakage in the C library
> >> and the C++ runtime. Since Darwin doesn't use ELF and apt doesn't use
> >
> >Not using ELF? That's almost unforgivable :P
>
> To be honest, I've grown fond of Mach-O. Almost everything it does is
> quite sensible, it just happens to be different from how it's done in
Even so, ELF is extendable, I'm sure you could tack in extra headers for
version info, etc.
It's maddening that after all these years we were finally getting
someplace with inter-unix standardization. Everyone was moving toward ELF,
POSIX is almost universally supported, SUSv2 was making excellent progress
in the commercial Unix's, and Apple of all people goes makes a new OS that
doesn't.
> I also dislike libtool (especially after trying to get it working
> 100% on Darwin and failing at 90%). Actually I really, really dislike
> anything that uses mass quantities of shell commands, i.e. the whole
APT used to have it long long ago, I ripped it out because it was horribly
slow and invasive for what little it did on Linux. Most other platforms
can live with static libs, or have equally simple options.
> in your build system. Support for using an already installed libtool
> command (like ncurses does it) is fine BTW, no need to add the whole
> stuff to your configure script. Let me know if I can be of assistance
> with this.
If you intend to actually use APT on darwin in any serious way it is
probably worth doing, I'd go about it by making a buildlib/ltprogram.mak
and ltlibrary.mak that calls out to libtool, make configure decide when
to switch those in.
> The global ctors work, but apparently they're only called when the
> class is first referenced. After all, apt wouldn't work if the ctors
> were broken completely, or am I missing something?
Class or variable? It is possible that the linker has somehow managed
to resolve away the circular references..
> Other stuff that breaks on Darwin: flushing standard output doesn't
> work as expected (had to insert fflush()'s), Apple recently broke
> mmap(), getaddrinfo() is broken as well (the headers even more so),
> there's a conflict between Makefile and makefile because the default
> file system is case-insensitive, and the socket functions don't like
> unsigned ints (there's no socklen_t of course). I can only hope that
> Apple cleans up the NextStep heritage some day...
MM, sounds like the older HP-UX's. Does Apple care if they are non-SUSv2
compliant?
Jason
Reply to: