3 ms·

How are shell scripts and flakey logic an improvement on Apple's cross-platform development/usage model? gcc -arch i386 -arch ppc -arch x86_64 -isysroot <SDK

How are shell scripts and flakey logic an improvement on Apple's cross-platform development/usage model? gcc -arch i386 -arch ppc -arch x86_64 -isysroot <SDK path> example.c -o example Done. > file example example: Mach-O universal binary with 3 architectures example (for architecture i386): Mach-O executable i386 example (for architecture ppc7400): Mach-O executable ppc example (for architecture x86_64): Mach-O 64-bit executable x86_64 I can even transparently run PPC binaries on my x86 Mac. Universal binaries are a core component of this easy-to-use (for developers and users alike) architecture independence.

vidarh 17y ago
What you are demonstrating is the userland toolchain. What was suggested above is an improvement by not requiring meddling with the kernel. Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications.
- antonovka 17y ago
  What you are demonstrating is the userland toolchain. No, what I'm demonstrating is an end-to-end architecture-transparent platform, which includes a complete userspace toolchain, a universal binary format, and necessary kernel and dynamic linker support. What was suggested above is an improvement by not requiring meddling with the kernel I'm not sure I understand how "meddling" in the kernel is a bad thing when it provides for user-transparent execution of multi-architecture binaries, including transparent emulation of binaries that lack support for the host architecture. It's not as if it's complex or dangerous to parse the Mach-O or FatELF formats, and if you take a page from Mac OS X or qemu, you can even do transparent emulation in userspace. Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications. How is it useful to build an easy-to-use multi-architecture binary if the kernel can't actually execute it? Why are you afraid of doing simple parsing[1] of the binary? The kernel already does this -- how do you think ELF loading and shell script execution works? I can imagine this conversation 30 years ago[2] -- "Why should we add shell script shebang parsing/execution support to the kernel? Why not just glue together loader executables that load the shell script" [1] The dead simple Mach-O universal binary loading code: http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-1228#L563 http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-... [2] The introduction of shebang in UNIX: http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html
  - thingie 17y ago
    It shouldn't be hard to make an binfmt_misc handler that would rip the correct elf from the fatelf thing (or rather a simple tar) and feed it to kernel, so you can just type ./fatelf-something. You can also make it a shell script with the binary in it, that will choose the correct one and execute it. Both these solutions works without a single kernel line (really), and I can't see anything that fatelf has and these doesn't.

vidarh 17y ago

What you are demonstrating is the userland toolchain. What was suggested above is an improvement by not requiring meddling with the kernel. Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications.

antonovka 17y ago
What you are demonstrating is the userland toolchain. No, what I'm demonstrating is an end-to-end architecture-transparent platform, which includes a complete userspace toolchain, a universal binary format, and necessary kernel and dynamic linker support. What was suggested above is an improvement by not requiring meddling with the kernel I'm not sure I understand how "meddling" in the kernel is a bad thing when it provides for user-transparent execution of multi-architecture binaries, including transparent emulation of binaries that lack support for the host architecture. It's not as if it's complex or dangerous to parse the Mach-O or FatELF formats, and if you take a page from Mac OS X or qemu, you can even do transparent emulation in userspace. Nothing prevents a userland toolchain for Linux from supporting what you are describing above without kernel modifications. How is it useful to build an easy-to-use multi-architecture binary if the kernel can't actually execute it? Why are you afraid of doing simple parsing[1] of the binary? The kernel already does this -- how do you think ELF loading and shell script execution works? I can imagine this conversation 30 years ago[2] -- "Why should we add shell script shebang parsing/execution support to the kernel? Why not just glue together loader executables that load the shell script" [1] The dead simple Mach-O universal binary loading code: http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-1228#L563 http://fxr.watson.org/fxr/source/bsd/kern/kern_exec.c?v=xnu-... [2] The introduction of shebang in UNIX: http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html
- thingie 17y ago
  It shouldn't be hard to make an binfmt_misc handler that would rip the correct elf from the fatelf thing (or rather a simple tar) and feed it to kernel, so you can just type ./fatelf-something. You can also make it a shell script with the binary in it, that will choose the correct one and execute it. Both these solutions works without a single kernel line (really), and I can't see anything that fatelf has and these doesn't.