Skip to content
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

Closed
ochipara opened this issue Oct 30, 2018 · 8 comments
Closed

native_posix fails to compile on macOS #10945

ochipara opened this issue Oct 30, 2018 · 8 comments
Assignees
Labels
area: native port Host native arch port (native_sim) Enhancement Changes/Updates/Additions to existing features priority: low Low impact/importance bug

Comments

@ochipara
Copy link

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

@aescolar
Copy link
Member

aescolar commented Oct 31, 2018

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.

@aescolar aescolar changed the title native_posix fails to compile native_posix fails to compile on MAC OS Oct 31, 2018
@nashif nashif added the bug The issue is a bug, or the PR is fixing a bug label Nov 2, 2018
@pfalcon pfalcon added the area: native port Host native arch port (native_sim) label Nov 6, 2018
@galak galak added the priority: low Low impact/importance bug label Nov 20, 2018
@nashif nashif added Enhancement Changes/Updates/Additions to existing features and removed bug The issue is a bug, or the PR is fixing a bug labels Jan 11, 2019
@marc-hb marc-hb changed the title native_posix fails to compile on MAC OS native_posix fails to compile on macOS Jun 28, 2019
@Emil-Gydesen-Bose
Copy link
Contributor

@ochipara I see that the error is clang: error: unknown argument: '-fno-freestanding'

Have you tried compiling with GCC instead of clang? I don't own a mac myself, but I've heard that gcc symlinks to the clang (llvm) compiler by default on macs, so that you think you have GCC, but you don't.

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.

@marc-hb
Copy link
Collaborator

marc-hb commented Dec 19, 2019

@ochipara I see that the error is clang: error: unknown argument: '-fno-freestanding'

I suspect this particular error is gone with a more recent XCode. On Mojave now:

$ clang --version
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
$ clang --help | grep standing
  -ffreestanding          Assert that the compilation takes place in a freestanding environment

I don't own a mac myself, but I've heard that gcc symlinks to the clang (llvm) compiler by default on macs, so that you think you have GCC, but you don't.

This is correct. Don't invoke gcc on a Mac, it's deceptive (unless you installed it yourself). Use clang.

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.

The most likely easiest: https://formulae.brew.sh/formula/gcc

@raveslave
Copy link

I suspect this particular error is gone with a more recent XCode.

I'm on latest os + xcode Apple clang version 11.0.0 (clang-1100.0.33.16, not getting the fno- error, but instead a bunch of ../kernel/include/kernel_offsets.h:27:1: error: unknown directive

@raveslave
Copy link

any plans to support LLVM/Xcode on macOS or should we use gcc for the native_posix use case (on mac)?

@aescolar
Copy link
Member

@raveslave No plans wrt macOS and native_posix

@eanderlind
Copy link

Building zephyr/samples/hello_world with gcc (10.2 installed via homebrew, with a manual link ln -s /usr/local/bin/gcc-10 /usr/local/bin/gcc) on macOS 10.15.7 (ie only 64-bit supported) with
west build -b native_posix_64 -d build_posix64
selects correct gcc toolchain, however stumbles when compiling ``zephyr/arch/posix/core/offsets/offsets.c`with errors

../../../kernel/include/kernel_offsets.h:28:2: error: unknown directive
        .type   ___cpu_t_current_OFFSET,@object
        ^
../../../kernel/include/kernel_offsets.h:29:2: error: unknown directive
        .type   ___cpu_t_nested_OFFSET,@object
        ^
../../../kernel/include/kernel_offsets.h:30:2: error: unknown directive
        .type   ___cpu_t_irq_stack_OFFSET,@object
        ^    (truncated the rest..)

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?
(-m64 flag was set, but zephyr/.config didn't have any flags containing X86)

Note: With same setup, west build -b qemu_x86_64 -d build_qemu64 also fails - it incorrectly selects the
gccarmemb toolchain even when creating a new build dir (and complains it doesn't understand `m64 flag).
Logic for selecting target seems incorrect for this case.

Building west build -b qemu_cortex_m3 is successful.

@cfriedt cfriedt added dev-review To be discussed in dev-review meeting and removed dev-review To be discussed in dev-review meeting labels Jul 28, 2021
cfriedt added a commit to cfriedt/zephyr that referenced this issue Aug 14, 2021
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]>
cfriedt added a commit to cfriedt/zephyr that referenced this issue Sep 16, 2021
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]>
@zephyrbot
Copy link
Collaborator

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!

@aescolar aescolar closed this as not planned Won't fix, can't repro, duplicate, stale Feb 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: native port Host native arch port (native_sim) Enhancement Changes/Updates/Additions to existing features priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.