-
Notifications
You must be signed in to change notification settings - Fork 51
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
Iodine fails to build on alpine 3.21 [gcc (14.2.0-r4)] #156
Comments
Hi @michal-kazmierczak , Thank you for bringing this to my attention. Do you have a docker file I could use for testing this? There really shouldn't be a problem between the two compilers. If you have installation logs, maybe we could find the issue in there. Also, could you please see if iodine 0.8 (development version) installs properly. It should work well enough for now except it doesn't have Redis support just yet. Thanks! |
Hi, the compilation error is:
Iodine 0.8 compile with success. Two Docker files to test Alpine 3.21 with both Iodine versions
KR |
Thank you @boazsegev for a quick response and @fabio for your input 🙇 I've included my Dockerfiles in my original message in the collapsible sections ( I can also confirm that 0.8 compiles on alpine3.21. |
Hi, Thanks for pointing out the details I've missed. I committed a patch to GitHub, but I'm not sure when (and if) it will be released. This patch might break backwards compatibility, as I have no idea how the system routing happens when calling On the newer By the way, how is the 0.8.0.dev version working for you? Did you try it? I still need to update and police some details (such as which tasks run on worker threads and which tasks run on the root / IO thread), and the Redis implementation is still missing (I need to rewrite it for scratch for the new Redis protocol)... but it should be quite solid (even more solid than the 0.7.x architecture). The rewrite changes the core architecture, which should still prevent new clients from connecting to busy workers while also improving IO performance for existing (connected) clients, improving static file service availability (for connected clients), improving worker process load balancing, improving slow client and buffering resilience (slowloris immunity) and maintaining IO performance when all Ruby threads are busy with slow requests. Also, the new architecture provides solutions for long-polling and streaming, utilizing NeoRack's approach and following its Specifications. This, of course, isn't necessarily a good fit for every app / route, but it's definitely shaping up to be a great tool for some micro-services that use WebSocket / SSE connections and publish or listen to an event stream. Thanks for reading... I'm a bit excited about the new version and so I may have over-responded. Good luck, |
It works fine in testing. I can't test it as much as I would like with a production load because my largest application uses Redis. I'm looking forward to trying it out on a production server with Redis implementation. Thanks for the updates and information you provided. KR, |
When is 0.8.0 going to be released? |
Hi @akostadinov , thanks for your interest. I'm mostly done, I think. I plan to release iodine once I finish the Redis Engine module (if I don't give up on it). I was also hoping to finish the DataBase integration design, just in case it requires changes to the core API, but I'm doubtful if I will wait with the release until that's done. I just need to cover all the existing features to avoid breakage and this means implementing Redis. However, I didn't even start rewriting the Redis parser and engine. It requires a rewrite in order to take advantage of new Redis features... so it might be a while. B. |
Ok, no problems, just asking. I had to implement a workaround anyway. Happy holidays! |
Happy holidays :) A workaround? Would you mind opening a new issue and describing the issue. As the 0.8 version is still under development, perhaps we can find a solution that works well for you. Or, if you're using the iodine development version, perhaps we can add a commit tag that would prevent any further changes from breaking your release. As for Redis, I'm looking into leveraging the B. |
My workaround was to stick to alpine 3.20. Not a big deal for my use case. Thank you! |
System Information
Description
Minimum reproducible example:
Failing scenario (alpine3.21)
Passing scenario (alpine3.20)
Probably, what's the most interesting, here are the packages installed for alpine3.20 vs alpine3.21:
alpine3.21
alpine3.20
I haven't checked further into the backward-incompatible differences between
g++ (13.2.1_git20240309-r0)
andg++ (14.2.0-r4)
, but is this a known issue?The text was updated successfully, but these errors were encountered: