-
Notifications
You must be signed in to change notification settings - Fork 20
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
[MUSL] [chromium-based]: Build support for Musl #376
base: master
Are you sure you want to change the base?
Conversation
Added upstream patch for perfetto due to include linux and musl conflict, disabled shim allocator as it causes multiple errors without mallinfo implementation, ref_ptr_support requiring it and added mallinfo stub for particularly tricky code
I test my changes without unnecessary ifs, just in case
Whoosh! Almost done!! :) [48492/49360], compilation ongoing |
Error at the linking stage with symbols, solvable, but I think it is necessary to completely replace all static config.h, defining the behavior of musl equivalent to glibc |
Great! Electron built successfully |
Are you sure those two patches do not negatively affect other platforms? You don't have to put a single patch into a separate folder, while holding other patches in |
config.h changes only if musl is used I have never worked with ebuild, I thought to mark the header files somehow, will move it to files, thx! |
Some declarations remove implementations instead of making the implementation empty, which causes errors at link stage when these symbols should have been there, but they were not included in the final build due to incorrect declarations.
Some processes launched by electron as part of the tests are too lightweight and can lead to a race between the parent process and the child process
CLONE_SETTLS is not used correctly within Chromium, this behavior has been deprecated in musl and now returns EINVAL
Within the chromium sandbox, some function definitions could use syscalls that are forbidden for glibc, such as: shed_setschedulerer, mremap, membarrier, set_tid_address
This file is only required for the Kate editor
Are the files in this PR not minimal? What do you mean by "minimal"?
I won't be able to verify whether they work, if you can ensure it works on musl (and doesn't break other platforms) then why not. |
I mean, these patches can be ported to earlier ebuilds for electron, but now all patches are applied exclusively to the latest version, so is there any point in doing this?
I'll try to provide full functionality while I check if it behaves correctly in general at the system call level compared to glibc from flatpaks, but even with memory reallocation, alas, not without problems, huh |
If you're not using older versions of electron, why bother adapting patches? :D
Is it capable of building vscode, does it work? |
hah touche ;)
electron is fully functional, even managed to get a normal browsing experience, except perhaps debugging, for now I need to figure out if it's because of shim or a memory leak in pthread, but vscode itself can't compile at the stage of installing packages, SQLite at least complains about something |
much ado about nothing :\ |
unless you were paying more attention to warnings: gentoo-overlay/app-editors/vscode/vscode-1.93.1.ebuild Lines 2241 to 2245 in 5565721
;) Although I must admit, I haven't tried building 1.93 myself jet :-/
I'm not sure what fails on your system, but vscode needs at least 12G of ram to build and even then it might fail with OOM. PS: That condition is indeed badly formed and perhaps does not function as intended :D |
don't blame me, blame portage! ;)
just lost sight of it, and portage didn't stop working on eerror.. pkill -SIGSEGV emerge
can only tell how important rest is :0 |
Update: |
In the Chromium and Node.js sandbox, using pthread_getattr_np becomes impossible, as the virtual environment deceives libc, forcing it to cross protection boundaries at best. At worst, it will first allocate ~1.2TB of virtual memory 12 times in a loop using mremap
my first VSCode on musl after so long... 🥹 didn't have to apply patches, works great, of course, still need to check how it works with extensions, and there's a SIGSEGV when clicking the File button, but it's already awesome that it runs at all ;) |
huh there is a problem gtk4 seems not to be applicable to chromium yet, due to changes in API, some functions were marked as deprecated and the necessary debug flag is broken, it asks for
fixed via
now the build error looks like this
but at the same time
and it looks like this error is related to the fact that esbuild is linked to glibc, and it needs to be built manually under musl? |
ungoogled-chromium has official USE flag for that, I didn't bother implementing it in electron. Merely disabling official is not enough, there is a bug upstream (which you've just rediscovered), which I fixed in ungoogled this way: gentoo-overlay/www-client/ungoogled-chromium/ungoogled-chromium-129.0.6668.70_p1.ebuild Line 1620 in 479732e
|
Improvements for working with dragons #375