Closed Ehekatl closed 2 months ago
The problem appears to be in the includes declared in mini_racer
's ext/mini_racer_extension/mini_racer_extension.cc
file which was fixed in https://github.com/discourse/mini_racer/commit/c9f141b58eac9ef293237bcda1c3929b2d3b5c6f.
Ah, ignore my previous comment. That relates to an issue I had installing the mini_racer
gem to reproduce the issue.
I can only find one reference to fprintf
in the mini_racer
gem's ext/mini_racer_extension/mini_racer_extension.cc
file. Have you tried recompiling the gem?
👋 @Ehekatl ☝️
Same problem here and it's kind of sad :( Because of this I can not build a react-on-rails app :(
same problem
I also have the same problem, is this issue solved?
Same here :-(
Same here :-( In the meantime another soluton by be using multistage builds, and do the assets precompile on ubuntu and copy the results to alpine
I'm also running in to this problem
Same for me.
Hello all!
mini_racer depends on the libv8 gem which distributes a statically linked (against glibc) V8. At this point rubygems has no support for distributing binary gems that are linked against a specific standard library :(. I would really like to see this implemented there so I can release libv8 linked against musl.
Please take a look at these sections in libv8's README. I hope they're helpful for you:
https://github.com/cowboyd/libv8#use-with-different-standard-c-libraries
Any work arounds for this ?
Not unless you can make the debugging symbols being referenced available to the runtime. Without those this will continue to happen.
Is there a way to compile libv8 from source with the symbols?
@andreimic, how exactly do you want to do that? Make Rubygems compile the gem from source or create a binary .gem file you can distribute?
You can do both.
I have the same problem. But, btw, would asset-precompilation on ubuntu, and copying to the main image (that uses alpine) work?
I have the same problem. But, btw, would asset-precompilation on ubuntu, and copying to the main image (that uses alpine) work?
It's worth trying. 👍
I'm so sorry for not responding to this bug report sooner. Without an example Dockerfile
it's hard to know what's causing these segmentation faults. If you're still experiencing this problem then would you please reply with an example Dockerfile
which reproduces the error.
I suggest that you and any other future readers in a situation like this consider running containers based on Docker images that are based on a GNU C library, rather than trying to run binaries which weren't compiled for musl inside Alpine Linux. As an example, Debian currently provide "slim" Docker images for each of their releases which are ~ 30 MB compressed.
I'm using the latest version of glibc