tpoechtrager / osxcross

Mac OS X cross toolchain for Linux, FreeBSD, OpenBSD and Android (Termux)
GNU General Public License v2.0
2.85k stars 320 forks source link

Cannot compile and link assembly on linux using osxcross #307

Open hard-coded0 opened 2 years ago

hard-coded0 commented 2 years ago

Hello,

I am trying to compile and link assembly from Ubuntu Linux for osx

I have tried running

nasm -fmacho64 fun.asm
x86_64-apple-darwin14-ld fun.o

but I keep getting the error

ld: warning: directory not found for option '-F/System/Library/Frameworks/'                                                                                                                                                                                                    Undefined symbols for architecture x86_64:                                                                                                                                                                                                                                       "_main", referenced from:                                                                                                                                                                                                                                                         implicit entry/start for main executable                                                                                                                                                                                                                                  ld: symbol(s) not found for architecture x86_64 

I have also tried compiling my assembly using

x86_64-apple-darwin14-as fun.asm

but that gives me the error

fatal error: x86_64-apple-darwin14-as: unknown host architecture (can't determine which assembler to run)  

How can I do this?

Gcenx commented 2 years ago

To workaround this exact issue I’d ended up adding a symlink for System from the SDK.

I know really not ideal nor the correct way to fix this issue but since this was being used from within a docker image it didn’t matter too much.