Skip to content

Conversation

@guyush1
Copy link
Owner

@guyush1 guyush1 commented Apr 18, 2025

No description provided.

Copy link
Collaborator

@roddyrap roddyrap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't the most thorough pass, and I am still abroad, but I was very annoying with my comments :)

It's mostly syntactic comments though so it's not very relevant.

I will check the submodules when I return.

x86_loader_path = x86_toolchain_path / "x86_64-linux-musl" / "lib" / "libc.so"
shutil.copy2(x86_loader_path, "/lib/ld-musl-x86_64.so.1")

# Create the entrypoint with the updated path.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you not just create the docker with a build argument that will be added to the path?

This will remove the need for the really weird entry point.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, since changing env variables is done ONLY via the ENV keyword, and can't be done "dynamically", so we would have to paste the path hardcoded, which could make it hard to add new architectures (we do that automatically here :) )

Copy link
Collaborator

@roddyrap roddyrap Apr 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docker run --env ?

You can even use --env-file, if you want.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that this script run inside the docker. This means i cannot create the env file outside of it :(

Maybe i could have 2 separate scripts, one that downloads the toolchains, one that runs in the host that creates an env file. If you agree, i will open an issue to do it in a separate issue.

@guyush1 guyush1 marked this pull request as ready for review April 18, 2025 19:09
@guyush1
Copy link
Owner Author

guyush1 commented Apr 18, 2025

Closes #53

@guyush1
Copy link
Owner Author

guyush1 commented Apr 18, 2025

TODO: update documentation - explain why musl is recommended, etc...

guyush1 added 12 commits April 25, 2025 12:30
Now builds are cancellable via ctrl+c :)
We now invoke make install for all of these packages. We later on add
their include paths so that the compiler is aware of any needed headers.

This allows us to not be reliant on *-dev libaries, which are often
libc-based, and are not installed in our custom musl toolchains.
cicd does not have a tty device, but when a user is compiling, we would
like to offer him a tty interface (so that he could cancel builds, for
example).
We needed it for cross-installation of ncrusesw
The generic musl arm compiler in the musl.cc website is bugged - so i
downgraded the arm compiler to gcc-10, which seems to work.
We also install xz to the build directory, for a cleaner setup.
@guyush1 guyush1 merged commit 35e514f into develop Apr 25, 2025
12 checks passed
@roddyrap roddyrap mentioned this pull request Apr 25, 2025
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

Successfully merging this pull request may close these issues.

2 participants