Am 09.01.2006 um 21:07 schrieb David Waite:
>> /usr/bin/ld: can't locate file for: -lcrt0.o
> You are on a macintosh, aren't you? static compilation will not work;
> Apple leaves out that compiler runtime file on purpose to prevent it.
Just for the records: I found this on the darwin-development list.
Apple sais this is for compatibiliy. So kernel upgrades won't break
Its a bit weak for a chroot environment but for the rest I agree.
> Subject: darwin-development digest, Vol 3 #1134 - 12 msgs
> From: firstname.lastname@example.org
> Date: 26. Mńrz 2004 23:27:04 MEZ
> to quote Jim Magee (@apple) yesterday on the unix-porting list :
> You will absolutely NEVER get a single statically linked executable to
> work on both Jaguar and Panther. Using static linking of the system
> libraries into your application makes your binary compatibility
> situation worse - not better. You will potentially have to ship a
> separate version of your application to work with each and every
> distinct software update of Panther and Jaguar.
> It has been said before, but is worth repeating: We strive to keep
> (backward) binary compatibility at the interface to the system shared
> libraries. The internal interfaces/protocols/mechanisms that these
> libraries use to talk to the kernel (and other system-wide-servers) is
> free to change in order to fix bugs, get better performance, or
> additional features from the kernel/servers. But as long as you just
> use the interfaces provided by the dynamic libraries that match those
> modified kernel/servers, you're fine.
> The result: Programs that use the dynamic library interface to the
> system provided by Jaguar continue to work when executed against
> (compatible at the interface-level) versions of those libraries (that
> may talk a modified version of their internal protocols to the new
> kernel/servers on that version of the system).
> Now, compile up static versions of those same libraries (we cannot
> technically stop you with the source being open) and statically link
> your program against that, and it will be speaking those internal
> protocols to the kernel/servers directly. It has no dylib buffer. But
> it only speaks one very specific dialect of those internal protocols.
> The result: You just have effectively tied your application to only
> working with one particular kernel and one particular set of servers.
> You are -- in effect -- locked to executing correctly only against one
> very specific software update. Not at all what you had in mind!
> I think what you are missing is that the development environment
> you to build against and link against older versions (like the Jaguar
> versions) of those interfaces even though you are actually running
> Panther. The development environment ships with multiple versions of
> the SDKs. You pick the oldest version you want to support - specify
> that version to XCode (or manually through environment variables for
> non-XCode builds) build away, and you should work on that version and
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Jan 10 00:50:43 2006