-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
native_posix fails to compile on macOS #10945
Comments
Hi @ochipara , we have not tried to get native_posix working on mac OS and do know from a couple of people who tried that it does not work. |
@ochipara I see that the error is Have you tried compiling with GCC instead of clang? I don't own a mac myself, but I've heard that There's a couple of guides on how to download, build and install GCC on macs on the web, if you haven't already tried compiling with GCC. |
I suspect this particular error is gone with a more recent XCode. On Mojave now:
This is correct. Don't invoke
The most likely easiest: https://formulae.brew.sh/formula/gcc |
I'm on latest os + xcode |
any plans to support LLVM/Xcode on macOS or should we use gcc for the native_posix use case (on mac)? |
@raveslave No plans wrt macOS and native_posix |
Building
It looks like the struct member .type isn't defined for macOS. Any suggestions which include directive could be wrong and which .cmake file to modify? Note: With same setup, Building |
This was a bit of a hack, but it really highlights some of the things that we take for granted with Linux and otherwise with ELF-based targets. Specifically, on macOS: * the Mach-O binary file format: * lacks weak symbol support * lacks support for section names > 16 characters * prefixes all symbols with `_` * The assembler (both llvm & GNU) does not support the `.type` directive * Linker options are different with Apple's ld * unsupported: `--whole-archive` / `--no-whole-archive` * `-Map` becomes `-map` * linker script format is completely different * macOS uses `-Wl,-order_file` instead of `-Wl,-T` for linker script Details about the Mach-O binary format and linker-generated sections can be found at the links below: https://opensource.apple.com/source/xnu/xnu-4903.221.2/EXTERNAL_HEADERS/mach-o/loader.h.auto.html https://github.com/aidansteele/osx-abi-macho-file-format-reference https://stackoverflow.com/questions/17669593/how-to-get-a-pointer-to-a-binary-section-in-mac-os-x Fixes zephyrproject-rtos#10945 Signed-off-by: Christopher Friedt <[email protected]>
This was a bit of a hack, but it really highlights some of the things that we take for granted with Linux and otherwise with ELF-based targets. Specifically, on macOS: * the Mach-O binary file format: * lacks weak symbol support * lacks support for section names > 16 characters * prefixes all symbols with `_` * The assembler (both llvm & GNU) does not support the `.type` directive * Linker options are different with Apple's ld * unsupported: `--whole-archive` / `--no-whole-archive` * `-Map` becomes `-map` * linker script format is completely different * macOS uses `-Wl,-order_file` instead of `-Wl,-T` for linker script Details about the Mach-O binary format and linker-generated sections can be found at the links below: https://opensource.apple.com/source/xnu/xnu-4903.221.2/EXTERNAL_HEADERS/mach-o/loader.h.auto.html https://github.com/aidansteele/osx-abi-macho-file-format-reference https://stackoverflow.com/questions/17669593/how-to-get-a-pointer-to-a-binary-section-in-mac-os-x Fixes zephyrproject-rtos#10945 Signed-off-by: Christopher Friedt <[email protected]>
Hi @aescolar, This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person. Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason. @ochipara you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you. Thanks! |
Hi,
I am trying to compile hello_world for native_posix on an os x (high sierra). I am able to use cmake to generate the build files, but it fails during compilation. I am getting the following error
FAILED: zephyr/CMakeFiles/offsets.dir/arch/posix/core/offsets/offsets.c.obj
/usr/bin/gcc -DBUILD_VERSION=zephyr-v1.13.0-1408-g7700eb2a15 -DKERNEL -D_FORTIFY_SOURCE=2 -D_POSIX_C_SOURCE=200809 -D_XOPEN_SOURCE=600 -D_XOPEN_SOURCE_EXTENDED -D__ZEPHYR__=1 -I../../../kernel/include -I../../../arch/posix/include -I../../../soc/posix/inf_clock -I../../../soc/posix/inf_clock/include -I../../../soc/posix/include -I../../../boards/posix/native_posix -I../../../include -I../../../include/drivers -Izephyr/include/generated -m32 -Os -g -Wall -Wformat -Wformat-security -Wno-format-zero-length -imacros /Users/ochipara/Working/embedded/r_and_r/zephyr/samples/hello_world/build/zephyr/include/generated/autoconf.h -ffreestanding -Wno-main -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -Wno-pointer-sign -Werror=implicit-int -Wpointer-arith -ffunction-sections -fdata-sections -fno-freestanding -m32 -MMD -MP -include /Users/ochipara/Working/embedded/r_and_r/zephyr/arch/posix/include/posix_cheats.h -std=c11 -MD -MT zephyr/CMakeFiles/offsets.dir/arch/posix/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/posix/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/posix/core/offsets/offsets.c.obj -c /Users/ochipara/Working/embedded/r_and_r/zephyr/arch/posix/core/offsets/offsets.c
clang: error: unknown argument: '-fno-freestanding'
I remove the '-fno-freestanding' flag from ninja.build, then I am running into additional errors due to not finding the macros GEN_OFFSET_SYM and GEN_ABSOLUTE_SYM. Any help in getting the sample to compile for native_posix would be appreciated.
Thanks,
-- Octav
The text was updated successfully, but these errors were encountered: