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

Implement linking without depending on external binaries such as ld #173

Open
certik opened this issue Aug 15, 2022 · 0 comments
Open

Implement linking without depending on external binaries such as ld #173

certik opened this issue Aug 15, 2022 · 0 comments

Comments

@certik
Copy link
Contributor

certik commented Aug 15, 2022

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/45

Currently we depend on either gcc and the standard libc, or with the --ld-musl flag on ld and musl. It would be nice to be able to compile executables without depending on any external package.

To do so, we have to link the .o files ourselves (see also numba/llvmlite#311). One can use link_in() in llvmlite to link the LLVM modules together, then we have just one .o file. Then we need to convert it into an executable.

  1. The first step is to do it without linking against any other library (such as libc). Here are some initial pointers how to do get started on that:
    https://blogs.oracle.com/linux/hello-from-a-libc-free-world-part-1-v2
    https://blogs.oracle.com/linux/hello-from-a-libc-free-world-part-2-v2
    http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
    https://stackoverflow.com/a/2548601/479532

  2. The second step is to figure out how to link in other libraries (such as libc and others).

The compiler will have several options:

a) use gcc to link (already implemented as default)
b) use ld to link (already implemented as --ld-musl)
c) or our own linking (to be implemented, see above)

The advantage of a) is that it works on all platforms easily, but one depends on gcc. The advantage of b) is that it doesn't require gcc, but it is more platform dependent. The advantage of c) is that it doesn't depend on any external package, and so the compiler is completely self-contained/self-sufficient to produce executables, but we have to implement the functionality of a linker, which is specific to each platform.

I think a good plan for c) is to start with a simple proof of concept that works, and then keep improving it. It doesn't have to be feature complete right away, as one can use a) or b) for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant