[Support] Add MacOS as a host for ELD

[Dhruv Menon (malto101)]

This PR adds MacOS support as a host for ELD (not a Mach-O target)

CMake detecs Darwin, uses "@loader_path" rpath and a kinda "bin/lib" layout, and skips GNU ver scripts on ld64

Runtime supports ".dylibs" plugins, Mach-O plugin metadata and "DYLD_LIBRARY_PATH/@loader_path" search. Lit gains Darwin features and FileChecks also accepts .dylib

also this was on my side
tried fixing "target_link_libraries" keyword that was mixed, it was breaking CMake on LLVM 22 on my host

[Shankar Easwaran (quic-seaswara)]

Wow! Thanks for adding this support.

Could you please add a github workflow to accompany and allow it to be tested on a mac ?

You would need to add

runs-on: macos-latest

[Dhruv Menon (malto101)]

Could you please add a github workflow to accompany and allow it to be tested on a mac ?

I have added the support

[Shankar Easwaran (quic-seaswara)]

Do you plan on working and improving eld ? If so what areas are you planning to look at ?

[Shankar Easwaran (quic-seaswara)]

one cause of concern here is that this is a CI instead of a nightly job(using github schedules). Since we are using the github free machines, it will significantly slow down CI as the CI that we have runs on self-hosted machines.

I would prefer this to be a nightly job instead of a CI.

Can we do this, and allows you to work independently to debug things if something ends up breaking and not affecting CI's.

For now its definitely ok to see if the CI passes, but once the CI passes move it to nightly schedule.

[Dhruv Menon (malto101)]

onee cause of concern here is that this is a CI instead of a nightly job(using github schedules). Since we are using the github free machines, it will significantly slow down CI as the CI that we have runs on self-hosted machines.

Makes sense, once the job pass I will move the schedule to nightly

or maybe we can have a bot to start CI jobs based on tags along with nightly?

[Dhruv Menon (malto101)]

Do you plan on working and improving eld ? If so what areas are you planning to look at ?

Happy to keep contributing, though it'll be sporadic. I usually only work on this in my free time — traditionally I'm mostly on Zephyr, kernel, BeagleBoard for OSS stuff.
I got curious after Parth's talk at the recent Zephyr conference at hyd, started digging into eld after that, and this PR was the first thing that felt useful to try (I develop on a Mac).
If I keep poking at it, the areas I'd naturally look at are:

• Host / CI / DX: Darwin support, nightlies, making it easier to build and test eld outside Linux
• Zephyr: GNU ld / linker-script compatibility that shows up in Zephyr nightlies, quarantine, and bringing more boards through
• Smaller cleanup / tests / docs as I run into them

Happy to take pointers if there's something more useful for me to look at.

[Steven Ramirez Rosa (Steven6798)]

Happy to take pointers if there's something more useful for me to look at.

Thanks for the contribution! While we have issues already posted, you can work on anything that feels natural and you think will benefit ELD and its users. This PR is going in the right direction.

[Shankar Easwaran (quic-seaswara)]

Do you plan on working and improving eld ? If so what areas are you planning to look at ?

Happy to keep contributing, though it'll be sporadic. I usually only work on this in my free time — traditionally I'm mostly on Zephyr, kernel, BeagleBoard for OSS stuff. I got curious after Parth's talk at the recent Zephyr conference at hyd, started digging into eld after that, and this PR was the first thing that felt useful to try (I develop on a Mac). If I keep poking at it, the areas I'd naturally look at are:

• Host / CI / DX: Darwin support, nightlies, making it easier to build and test eld outside Linux
• Zephyr: GNU ld / linker-script compatibility that shows up in Zephyr nightlies, quarantine, and bringing more boards through
• Smaller cleanup / tests / docs as I run into them

Happy to take pointers if there's something more useful for me to look at.

Appreciate the reply. More boards mean more testing opportunities.

We're also focused on improving link-time performance, enhancing diagnostics, expanding reproducibility features for debugging, and adopting proven capabilities from BFD and LLD that can benefit both general-purpose and embedded linking use cases.

Another area where contributions are valuable is expanding support for command-line options and improving compatibility with existing linker workflows, making it easier for users to migrate and adopt ELD in a wider range of environments.

Leveraging linker plugins, which are already quite robust in ELD, within Zephyr could also be an effective way to address a number of challenges.

There's plenty of value in helping improve documentation as well. Learning, documenting, and sharing best practices are all meaningful contributions.

And of course, if you're interested in code size optimization, linker optimizations, or performance tuning, there are plenty of opportunities there too.

Overall, any patches are welcome!

[Steven Ramirez Rosa (Steven6798)]

Dhruv Menon (@malto101) to prevent having failures in tests due to missing tools (which could be expanded at any point), you can use "ninja" instead of "ninja ld.eld clang" to build everything. That will eliminate these kinds of failures.

[Dhruv Menon (malto101)]

Dhruv Menon (Dhruv Menon (@malto101)) to prevent having failures in tests due to missing tools (which could be expanded at any point), you can use "ninja" instead of "ninja ld.eld clang" to build everything. That will eliminate these kinds of failures.

Thanks Steven Ramirez Rosa (@Steven6798) it helped a lot

[Shankar Easwaran (quic-seaswara)]

Please make this ci-macos to be a nightly-macos.yml.

I will be able to approve this.

Thanks for getting this!