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

Fails to build with GCC 15 (dependency onig_sys) #956

Closed
creideiki opened this issue Dec 2, 2024 · 4 comments · Fixed by #957
Closed

Fails to build with GCC 15 (dependency onig_sys) #956

creideiki opened this issue Dec 2, 2024 · 4 comments · Fixed by #957
Labels
bug Something isn't working

Comments

@creideiki
Copy link
Contributor

I'm not sure if broot can actually do anything about this, but other packagers will hit it eventually once GCC 15 is released, so here's a heads up:

Gentoo has started experimenting with using prereleases of GCC 15 as the system C compiler. When that is the case, onig_sys, which is a dependency of broot, fails to build. Downstream bug: https://bugs.gentoo.org/943785

onig_sys contains a copy of the Oniguruma C source code, which is used by default. That copy is very old, and in particular does not include the fixes from kkos/oniguruma#312 for GCC 15 compatibility.

I've filed a bug (rust-onig/rust-onig#191) and asked for an updated snapshot in onig_sys, but that project does not seem to be particularly actively maintained.

What I did instead in Gentoo was to tell onig_sys to use the system copy of the Oniguruma library (in Gentoo this is release 6.9.9 + GCC 15 patches), by setting the environment variable RUSTONIG_SYSTEM_LIBONIG=1. This seems to work, but means we're using a newer Oniguruma than intended.

Would you be interested in building other packages the same way, so we'll at least all be testing with vaguely the same version of Oniguruma? Or do you have some other suggestion of how to handle this problem?

@creideiki creideiki added the bug Something isn't working label Dec 2, 2024
@Canop
Copy link
Owner

Canop commented Dec 2, 2024

I think we can just build without onig (which is used in syntect). I'm testing whether it has some impact (might impact the performances of code preview).

Canop added a commit that referenced this issue Dec 2, 2024
@Canop
Copy link
Owner

Canop commented Dec 2, 2024

@creideiki Is the problem solved with #957 according to you ?

@creideiki
Copy link
Contributor Author

Seems to work, with my limited testing - #957 builds with GCC 15 and still gives me syntax highlighting in source code.

@Canop
Copy link
Owner

Canop commented Dec 2, 2024

I didn't remove syntect, just compiled it so that it uses another regex lib, a pure rust one. So it probably works ok but there might be subtle bugs...

@Canop Canop closed this as completed in #957 Dec 3, 2024
@Canop Canop closed this as completed in ab6b69e Dec 3, 2024
Canop added a commit that referenced this issue Jan 1, 2025
This fork doesn't panic on non compiling regexes.

Fix #967

The reason the fork is needed is that syntect panics when a regex from a syntax can't compile, which happens with sublime syntaxes when the engine isn't onig but fancy-regex.

The default regex engine of syntect is onig, but this unmaintained engine isn't pure-rust and isn't compatible with gcc 15, which limits compatibility for broot. So, right now, this fork is useful to prevent crashes.

The ideal solution would be either to have syntect completely handle regex compiling errors without panic (which looks easily doable but requires some work and may not appear as the best behavior for some other crates using syntect) and|or to have fancy-regex support all the regex features that are required by sublime syntaxes.

See also:
* fancy-regex/fancy-regex#74
* sharkdp/bat#3156 
* #956
* trishume/syntect#508
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants