How to build SML/NJ executable on Mac - macos

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.

Related

How to run this bash code on macOS Monterey [duplicate]

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.

Cross compiled binary not running on RPI, did I compile it correctly?

I am trying to cross compile a small rust application for the RPI. I am cross compiling because compiling directly on the PI takes way too long and it hits 75C.
I followed various instructions, but what I ended up doing is this:
Install "armv7-unknown-linux-gnueabihf" target with rustup
Download rpi tools from here: https://github.com/raspberrypi/tools
Add the "tools/arm-bcm2708/arm-linux-gnueabihf/bin/" folder to PATH
Add ".cargo/config" file with:
[target.armv7-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc"
run "cargo build --target armv7-unknown-linux-gnueabihf --release"
scp the file to the RPI
chmod +x the_file
do "./the_file"
I get bash: ./the_file: No such file or directory
Yes, I am indeed in the right directory.
So this is the output from "file":
ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically
linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
with debug_info, not stripped
I'm not experienced enough with this sort of stuff to determine if the binary that I produced is suitable to be run on an RPI3 B.
Did I produce the correct "type" of binary?
P.S. I am running DietPi distro on the PI. It is based on debian if that's of any relevance.
So I solved this by cheating. I found https://github.com/rust-embedded/cross which took about 30 seconds to get going and now I can cross compile to pretty much anything. I highly recommend it!
The error message "No such file or directory" is not about the your executable but about the dynamic libraries linked to it which are missing from the target system.
To find out which libraries your executable needs you have to run the following command.
ldd /usr/bin/lsmem
This will output something like this
linux-vdso.so.1 (0x00007fffc87f1000)
libsmartcols.so.1 => /lib/x86_64-linux-gnu/libsmartcols.so.1 (0x00007fe82fe71000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe82fc7f000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe82fedd000)
Now you have to check that all this libraries are available on your system. rust-cross probably uses the correct linker for your target so that is probably the reason this works with it. To modify the linker see https://stackoverflow.com/a/57817848/5809980

ld: file not found: elf_i386 error on Mac Terminal

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.

mingw32-make tries to create subfolder .lib an illegal name

I am trying to compile a project that required freetype library so I was figuring out how to install freetype to mingw32 and the more safer way is to compile it.
Anyway the problem was compiling freetype-2.4.11
I went into bash provided in msys
I did ./configure within freetype's main dir and everything looks fine
next I did mingw32-make which created the problem
libtool: compile: gcc -pedantic -ansi -Ig:/Downloads/freetype-2.4.11/objs -I./b
uilds/unix -Ig:/Downloads/freetype-2.4.11/include -c -Wall -g -O2 "-DFT_CONFIG_C
ONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" g
:/Downloads/freetype-2.4.11/src/base/ftsystem.c -DDLL_EXPORT -DPIC -o g:/Downlo
ads/freetype-2.4.11/objs/.libs/ftsystem.o
Assembler messages:
Fatal error: can't create g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o: No
such file or directory
g:/Downloads/freetype-2.4.11/builds/freetype.mk:198: recipe for target 'g:/Downl
oads/freetype-2.4.11/objs/ftsystem.lo' failed
mingw32-make[4]: *** [g:/Downloads/freetype-2.4.11/objs/ftsystem.lo] Error 1
g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o seemed like it is trying to use a directory that is illegal in windows.
Thanks in advance
Try to use make instead (i.e. the one from MSYS distribution), and avoid using mingw32-make (from MinGW distribution) in the future to save yourself time and nerves. Extract from MinGW Wiki:
What's the difference between make and mingw32-make?
The "native" (i.e.: MSVCRT dependent) port of make is lacking in some functionality and has modified functionality due to the lack of POSIX on Win32. There also exists a version of make in the MSYS distribution that is dependent on the MSYS runtime. This port operates more as make was intended to operate and gives less headaches during execution. Based on this, the MinGW developers/maintainers/packagers decided it would be best to rename the native version so that both the "native" version and the MSYS version could be present at the same time without file name collision.

How to change architecture mac os x

Hi all I need to change architecture type in the file.
when I do lipo -info command I get only arm7 but I need to have i386 next to it.
Is there any command that can add me i386 info inside the file?
Yes, it's called cc, but it depends on some minor configuration files (*.m or *.c files).
Edit: Sorry for not making the joke obvious. What I wanted to say is:
There's not way to change the architecture of an executable file. Executables are produced by compiling source code to machine code and this process is not reversible. You'll need the original source code to recompile the project to the missing architecture. Then you can use lipo to combine the executables to a fat binary.

Resources