You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
New build failure on 2.7.4-alpine-amd64 (maybe revisit #364?) #365
Sure looks like #364 broke my build. Specifically, I'm on 2.7.4-alpine on amd64 and the short version is that every single gem with native dependencies that bundle tried to install failed.
FROM ruby:2.7.4-alpine
RUN apk add --no-cache build-base
WORKDIR /app
RUN printf "source 'https://rubygems.org'\nruby '2.7.4'\ngem 'racc'" > Gemfile
RUN bundle install
Building this will fail, but if you s/7.4/6.8/, it builds fine.
I'm seeing the same issue with all builds of native gems on the latest 2.7.4-alpine3.14 - complaints about "cannot find -lucontext", for example when building bcrypt:
linking shared-object bcrypt_ext.so
/usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../x86_64-alpine-linux-musl/bin/ld:
cannot find -lucontext
collect2: error: ld returned 1 exit status
make: *** [Makefile:262: bcrypt_ext.so] Error 1
make failed, exit code 2
AFAICT the lib is only needed at build time for gems with native extensions...seems like using gems with native extensions works, even if -lucontext was passed to the linker during the build. I guess if it doesn't actually use the lib, then it's basically a no-op? Then I guess it's not actually getting used in the ruby build on x86_64? This is totally unimportant, and I'm totally curious 😁
@keithlayne correct -- it's only even necessary on three architectures, so fixing it to be architecture-conditional (and keeping libucontext-dev on the affected architectures) is #366
Activity
keithlayne commentedon Oct 27, 2021
Also, just so this is clear, my image build failures began immediately after the most recent push to docker hub.
bpo commentedon Oct 27, 2021
I'm seeing the same issue with all builds of native gems on the latest 2.7.4-alpine3.14 - complaints about "cannot find -lucontext", for example when building bcrypt:
keithlayne commentedon Oct 27, 2021
Ugh, I feel dumb, I skimmed over those log lines and missed them, but those make it obvious I think that #364 is the culprit.
keithlayne commentedon Oct 27, 2021
Found a workaround that also should have been obvious: add
libucontext-devviaapk. Can confirm this fixes my build for the moment.keithlayne commentedon Oct 27, 2021
Seems like that's included for the build of ruby? So I more probably need to add
libucontextbecause ruby needs it at runtime...will test.tianon commentedon Oct 27, 2021
Ooof, just went to file this issue myself -- thanks for chasing this down with some good details, folks. 😄
I guess we ought to make #364 actually conditional and only apply it for architectures which do require it. 😩
The other option would be to just always keep
libucontext-devinstalled, which would add ~249KB to our overall image size. 🤔tianon commentedon Oct 27, 2021
(To be clear - @yosifkit is currently typing up a solution and should have a PR open ASAP.)
cameronbourgeois commentedon Oct 27, 2021
keithlayne commentedon Oct 27, 2021
AFAICT the lib is only needed at build time for gems with native extensions...seems like using gems with native extensions works, even if
-lucontextwas passed to the linker during the build. I guess if it doesn't actually use the lib, then it's basically a no-op? Then I guess it's not actually getting used in the ruby build on x86_64? This is totally unimportant, and I'm totally curious 😁tianon commentedon Oct 27, 2021
@keithlayne correct -- it's only even necessary on three architectures, so fixing it to be architecture-conditional (and keeping
libucontext-devon the affected architectures) is #366cameronbourgeois commentedon Oct 28, 2021
tianon commentedon Oct 28, 2021