site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Am 06.10.2004 um 18:24 schrieb Quinn: Thanks a lot for the detailed answer, Quinn. Cheers, Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 11:30 +0200 10/9/04, Markus Hitter wrote: But where comes dyld into this play? Is the binary communicating directly with dyld? "nm ls" shows up some entries named "dyld_...". ELF binaries should have the appropriate functions for the elf linker, then. ... The upshot of this is that dyld is mapped into the process's address space and is the first code that's run. Sounds like I want to assemble some combined ELF & Mach-O Loader which loads ELF binaries and dynamically links them against ELF libraries (those deployed with the app) as well as Mach-O libraries (unless I want to provide a complete set of the foreign system libraries). So far I don't see a need to patch the kernel since mapping can be done in a user land app as well. Your words seem to confirm this. Still lots of stuff to absorb before I can start to assemble the puzzle ;-) This email sent to site_archiver@lists.apple.com