when i run a command in terminal (Using El Capitan)
ld -m elf_i386 -T linker.ld -o kernel kasm.o kc.o
It shows the following error :
ld: warning: option -m is obsolete and being ignored
ld: file not found: elf_i386
Can anybody help me with this?
when i run a command in terminal
You are trying to link some kind of kernel using ld directly. This is actually one of very few cases where using ld directly is appropriate.
However, the command line arguments you give to ld assume that you are using GNU-ld (you may have copied them from a Linux tutorial), but you are not using GNU-ld, you are using MacOS native linker, which doesn't understand these arguments.
Can anybody help me with this?
Please ask a separate question, along the lines of "I am trying to build XXX on MacOS, following tutorial YYY, and don't understand how to adjust this Linux command to Mac OS".
Note that it may not be possible to build XXX on MacOS at all. In particular, the ld manpage does not mention ELF as possible output, so if your "build XXX" goal includes building an ELF kernel, you'll likely need to build a cross-linker (a GNU-ld linker which runs on Mac OS (i.e. hosted on Mac OS), but produces code for ELF target.
Related
I'm trying to compile and link an assembly file to an executable with NASM and the standard LD linker on my MacBook Air M1. I have no problems with getting the .o file, but if I want to link it with LD, it throws that error:
ld: file not found: elf_i386
Command:
ld -m elf_i386 -s -o hello hello.o
What do I have to change?
Those are options for GNU ld on x86 Linux. (Note the ELF part of the target object-file format, and the i386). MacOS uses the MachO object-file format, not ELF, and apparently their ld takes different options.
Also, MacOS hasn't supported 32-bit x86 for a few versions now, so an M1 mac with an AArch64 CPU definitely can't run 32-bit x86 executables natively.
So get an emulator for a 32-bit Linux environment if you want to follow a tutorial for that environment, or find a tutorial for AArch64 MacOS. Or possibly x86-64 MacOS which should still work transparently thanks to Rosetta, but make sure single-step debugging actually works. That's an essential part of a development environment for learning asm.
Assembly language is not portable at all, you need a tutorial for the OS, CPU-architecture, and mode (32-bit vs. 64-bit) that you're going to built in. Don't waste your time trying to port a tutorial at the same time you're learning the basics it's trying to teach. You'd have to already know both systems to know which parts of the code and build commands need to change.
When trying to run the ld command with the -melf_i386 option, i get this error:
ld -melf_i386 helloWorld.o -o hello
ld: unknown option: -melf_i386
This option does work on Linux.
How do I fix this?
You can't. macOS does not support ELF binaries, and its linker does not support ELF output. As such, the -melf_i386 option does not exist. (Indeed, the entire -m option for selecting an emulation does not exist either; macOS handles subarchitectures in a rather different way from Linux.)
If you are trying to create ELF binaries for a Linux system, you will need to install a cross-compile toolchain. I'm not aware of any prebuilt toolchains for this purpose; most developers targeting Linux systems do not compile software on macOS. A more viable option may be a Linux virtual machine.
If you are trying to create an ELF binary to run on the macOS system, you're out of luck. That isn't possible.
If you are trying to follow a tutorial on assembly programming, be warned that the macOS system call interface is not compatible with the one on Linux. Use a Linux system (or virtual machine) to follow this tutorial.
when i run a command in terminal (Using El Capitan)
ld -m elf_i386 -T linker.ld -o kernel kasm.o kc.o
It shows the following error :
ld: warning: option -m is obsolete and being ignored
ld: file not found: elf_i386
Can anybody help me with this?
when i run a command in terminal
You are trying to link some kind of kernel using ld directly. This is actually one of very few cases where using ld directly is appropriate.
However, the command line arguments you give to ld assume that you are using GNU-ld (you may have copied them from a Linux tutorial), but you are not using GNU-ld, you are using MacOS native linker, which doesn't understand these arguments.
Can anybody help me with this?
Please ask a separate question, along the lines of "I am trying to build XXX on MacOS, following tutorial YYY, and don't understand how to adjust this Linux command to Mac OS".
Note that it may not be possible to build XXX on MacOS at all. In particular, the ld manpage does not mention ELF as possible output, so if your "build XXX" goal includes building an ELF kernel, you'll likely need to build a cross-linker (a GNU-ld linker which runs on Mac OS (i.e. hosted on Mac OS), but produces code for ELF target.
The issue I'm having is that gcc (and family) don't appear to be properly setup. I have a 10.7.4 machine that I just installed Xcode on (from the app store). I've done no prior development on this machine.
Working w/in Xcode seems to work fine. I can build and compile no problem. However, trying to execute gcc command line fails.
First, I gcc wasn't on my path ... no big deal. I located it and ran as:
/Applications/Xcode.app/Contents/Developer/usr/bin/gcc -dynamiclib -fno-common -o s.dylib s.c
(I'm working on a lib w/some functions...). Anyways, it fails.
s.c:1:19: error: stdio.h: No such file or directory
s.c:2:20: error: stdlib.h: No such file or directory
s.c:3:20: error: string.h: No such file or directory
Surprise! hah, well I searched my machine for stdio.h and I can't find it anywhere. Since I've been out of the OSX game for a bit, I'm assuming I'm missing something -
Basically I want to be able to continue using Xcode but I want to be able to build C/C++/etc on the command line with all the dependencies (.h) in the correct place.
Any thoughts?
There are two main ways to run the compiler from the command line: the Command Line Tools package, and xcrun.
xcrun is particularly good if you just need this occasionally. Just stick "xcrun" at the start, like you'd do with sudo:
xcrun gcc -dynamiclib -fno-common -o s.dylib s.c
This will find the correct version of gcc and set the needed directories, etc. You can specify a specific SDK with --sdk.
If you do this a lot, download and install the Command Line Tools package (Xcode>Open Developer Tool>More Tools...; it also may be available in Preferences>Downloads). This installs a full copy of everything in /usr.
Probably xcrun is not enough if you are using 10.8.
Looking in to the clang documentation I found that you need to include the system root because you do not have your libraries in the standard place but inside Xcode.
using:
xcrun gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
or:
xcrun clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
I have an SML/NJ program that I can run as a heap image, and I want to create a standalone executable binary. However, the heap2exec tool in SML/NJ 110.73 always yields errors for me.
I created my heap image tigerc.x86-darwin via the following:
ml-build sources.cm Main.main tigerc
I can run my program fine using the heap image via
sml #SMLload=tigerc.x86-darwin
I should be able to create the standalone binary via
heap2exec tigerc.x86-darwin tigerc
but that generates the error
ld: warning: -macosx_version_min not specificed, assuming 10.7
ld: warning: ignoring file tigerc.o, file was built for unsupported file format
which is not the architecture being linked (i386)
I looked at the heap2exec shell script, and the key lines (variable-expanded) do the following:
heap2asm "$heapfile" "$execfile".s
cc -c -o "$execfile".o "$execfile".s
ld -o "$execfile" ${RUNX} "$execfile".o
When I run these steps individually, the cc command generates an x86_64 .o file, but the ld command is trying to link an i386 executable. So I need to convince the cc command to generate an i386 .o file as well.
Is there a way to set an environment variable to get cc to build i386 instead of x86_84? (ARCH doesn't do the trick, by the way — it's already set to i386.)
Or is there another workaround to get heap2exec to generate the right architecture?
Try adding CFLAGS=-m32 as an environment variable. That's the standard way to force it to build a 32-bit object file.
I know you're asking specifically about SML/NJ, but MLton has 64-bit support and makes this kind of task really easy. You might thank yourself later if you're in a position to use it to generate executable binaries instead.