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
the application.
Its a bit weak for a chroot environment but for the rest I agree.
Robert
> Subject: darwin-development digest, Vol 3 #1134 - 12 msgs
> From: darwin-development-request@lists.apple.com
> 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.
>
> Why?
>
> 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
> provide
> 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
> future
> (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
> allows
> 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
> beyond.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 10 00:50:43 2006