sassc-ruby: 2.2.0 causes LoadError
Encountered an issue when attempting to use Jekyll 4.0.0 on Fedora Workstation 30. Somewhat similar to #141. Jekyll 4.0.0 seems to depend on sassc 2.2.0 and when executing jekyll -v I observed an error message containing the following:
.gem/ruby/gems/sassc-2.2.0/lib/sassc/libsass.so: cannot open shared object file: No such file or directory (LoadError)
The “fix” I found is to downgrade Jekyll to version 3.8.6 and sassc to 2.1.0, after which the error no longer appears.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 27
- Comments: 107 (12 by maintainers)
Commits related to this issue
- Fix LoadError on some non-rvm environments Fixes sass/sassc-ruby#146. See also opal/c_lexer#1 for some discussion on the issue. — committed to hmdne/sassc-ruby by hmdne 5 years ago
- Update sassc to 2.2.1, to hopefully fix https://github.com/sass/sassc-ruby/issues/146#issuecomment-532760959 — committed to blerner/bottlenose by deleted user 5 years ago
- :ambulance: Work around sass/sassc-ruby#146 by building sassc not natively This disables -march=native -mtune=native, which disables CPU optimizations. Our server has an older CPU than Docker Hub, so... — committed to YtvwlD/mete by YtvwlD 5 years ago
- :ambulance: Work around sass/sassc-ruby#146 by building sassc not natively This disables -march=native -mtune=native, which disables CPU optimizations. Our server has an older CPU than Docker Hub, so... — committed to chaosdorf/mete by YtvwlD 5 years ago
- Default --march-tune-native to false Despite the warnings, people still build using a different environment than the deployment one. This doesn't actually make the built library portable, just less ... — committed to glebm/sassc-ruby by glebm 5 years ago
- Bump sassc and fix LoadErrors There seems to be a portability issue in the sassc gem that attempts to execute illegal instruction which subsequently manifest themselves as Ruby LoadErrors. The workar... — committed to CHTJonas/roombooking by CHTJonas 5 years ago
- add bundler build config to make sassc gem portable (#1809) * add bundler build config to make sassc gem portable was finding that images built on docker hub and used on our architecture would fa... — committed to ualbertalib/discovery by pgwillia 5 years ago
- Add config to Dockerfile to make sassc portable We had some issues in development that meant the Docker image fell over during boot. The solution outlined in https://github.com/sass/sassc-ruby/issues... — committed to DFE-Digital/claim-additional-payments-for-teaching by pezholio 4 years ago
- Downgrade sassc gem version from 2.2.1 to 2.1.0 https://github.com/sass/sassc-ruby/issues/146 — committed to rokumatsumoto/boyutluseyler by rokumatsumoto 4 years ago
- Disable native CPU arch optimization for sassc as it reduces portability Not disable this optimization causes random failures at Travis when using cached gems built on different CPU and also is a pro... — committed to SpeciesFileGroup/taxonworks by LocoDelAssembly 4 years ago
- Adding a bundle config variable for sassc to fix the bug https://github.com/sass/sassc-ruby/issues/146#issuecomment-541749126 — committed to glowfic-constellation/glowfic by Marri 4 years ago
- Do not deference links, try fix: sass/sassc-ruby#146 — committed to eclipse/packages by ctron 4 years ago
- :fingers_crossed: https://github.com/sass/sassc-ruby/issues/146 — committed to mike-webster/pet-tracker by deleted user 4 years ago
- Fix sassc-ruby https://github.com/sass/sassc-ruby/issues/146 — committed to ledermann/docker-rails-base by ledermann 4 years ago
- downgrade sassc to 2.1.0 sassc 2.2.0 includes precompiled binaries which aren’t compatible between different processor architectures, which means that we can't cache the rubygems and reuse them on a ... — committed to OfficeForProductSafetyAndStandards/product-safety-database by frankieroberto 4 years ago
- downgrade sassc to 2.1.0 (#250) sassc 2.2.0 includes precompiled binaries which aren’t compatible between different processor architectures, which means that we can't cache the rubygems and reuse the... — committed to OfficeForProductSafetyAndStandards/product-safety-database by frankieroberto 4 years ago
- Fix for https://github.com/sass/sassc-ruby/issues/146 The sassc gem compiles using -march=native which produces a non-portable c lib of sassc. In a Docker environment, the built image may be run on a... — committed to DFE-Digital/schools-experience by jebw 4 years ago
- Pin sassc to 2.1.0 https://github.com/sass/sassc-ruby/issues/146#issuecomment-528752874 — committed to bierik/libellum by bierik 4 years ago
[BUG] Illegal instruction
this option makes the binary NOT portable between different processor architectures https://github.com/sass/sassc-ruby/blob/8b6f4154355afcfc49174c87b6ddd7039ccbec8a/ext/extconf.rb#L24
I expect that you have a VM 1/ build sassc on your local machine 2/ deploy your preinstalled image on a cloud that has a different CPU
workaround 1/
2/ prebuild a portable gem
or
precompiled gem was originally portable https://github.com/sass/sassc-ruby/blob/8b6f4154355afcfc49174c87b6ddd7039ccbec8a/Rakefile#L26 but it was removed in https://github.com/sass/sassc-ruby/pull/145 thats why sassc 2.1.0 works for you
@glebm @bolandrm 1/ is it significantelly faster with -march=native? maybe we should disable this option by default to make it more portable? 2/ or at least add a note to README for people that want to use the same binary on VMs?
Thanks all for the tips above! Just to reiterate for anyone who doesn’t want to read the marathon thread above, the following solves the issue:
What I’m interested to know however is why this is necessary when running locally on a Mac? I’m not pulling a Docker image or other precompiled assets/binaries from CI etc. I’m literally just installing the gem natively - why does adding
-march=native -mtune=nativeto the compiler flags suddenly break everything?I have a similar issue. 😭 An error occurs when the probability is about 80%.
Environment Alpine3.10 + Ruby2.6.3p62 + Rails5.2.3 on AWS ECS (FARGATE).
I’m also getting this error in Docker, both locally and on Heroku. Here’s a release log from Heroku:
Setting
BUNDLE_BUILD__SASSCin theDockerfilefixes the issue:Having an official fix would make this much easier for folks.
@bolandrm thanks for the release. At least for us it still happenning:
Our docker file:
Released 2.2.1. Please try it out and let me know if it helped!
2.3.0 released, let us know if it helps out with some of these issues or not.
One of the devs here took the time to test the solution from @nicovigil1, and it actually worked, sorry for having responded without testing first.
He inserted these lines on the Dockerfile, before we install our gems:
Thanks @nicovigil1!
@glebm I don’t think compiling a docker image in a CI based on ubuntu and deploy the container on customer environment based on Centos 7 or Redhat 7 is a “niche use-case” in 2019 or in the future.
Fully portable binaries for Linux are basically impossible. I am not convinced that we should reduce performance for everyone for such a niche use-case.
Hi. At our company we are having a different problem, on several applications, we had always used this version of sassc (2.2.1), and we didn’t had any problem until yesteday, when we re-deployed a application (no major changes) and it raised
[BUG] Illegal instructionwhen trying to start rails.versions
The only thing that has really changed, is that the image from dockerhub that we use, ruby:2.6.5-alpine, has been changed in the last couple days.
Until now, we attempted most of the proposed solutions on this issue, but nothing worked. Anyone had similar problems?
I figured out a bit of a fix if you’re using Github Actions with
actions/cache@v1.1.2This is the caching
The Bundle Config
The bundle run
Bundle update will have to run each time ( at least for me, this could just be due to loading gems from Github ), but it uses previously cached gems & loads much quicker than a full
bundle installedit: If this doesn’t work, try running it with a new cache key, this fix wont work if it’s using the cached version of sassc ( with no --disable-march-tune-native )
For Github Actions I’m using the following workaround. It rebuilds
sassconce to make the build flag active.Have a load issue too with ruby:2.6.2-alpine3.9 and ruby:2.6.3-alpine3.8 running in AWS and in local server (with docker) When I build it in docker-hub or in codefresh the commands run ok, but when I deploy the app I have this issue with sassc 2.2.0.
With a downgrade to
sassc 2.1.0the issue is not happening…Also fails for me on CentOS 7 + Ruby 2.5. However unlike what was reported by OP, Jekyll 4.0 doesn’t seem to require sassc 2.2.0. Just adding
gem "sassc", "< 2.2.0"to my Gemfile worked around the bug successfully.When installing the extension from 2.1.0,
libsass.sois at~/.gem/ruby/2.5.0/gems/sassc-2.1.0-x86_64-linux/lib/sassc/libsass.so. When building it from 2.2.0, it is at~/.gem/ruby/2.5.0/gems/sassc-2.2.0/ext/libsass.so.I ran into this issue while installing
ffigem. Same thing that @brcarp mentioned above.The ffi gem was installing fine on MacOS Catalina but was failing in my Ubuntu18.04 docker container. Which led me to seeing which libraries are not included by default in my base image. Turns out it was
libffi-dev. Installinglibffi-devin my Dockerfile helped resolve this issue. Here is the command I usedI use sassc in jekyll blog build
Issue is solved for me - I added the following line to
Gemfile:gem "sassc", "~> 2.3.0"@piotrmankowski because the flag is
--disable-march-tune-native.There are a few typos in @ahorek’s comment (no blame! This comment pointed me in the right direction!)
Doesn’t break for us in production where we run Ubuntu + Passenger + Rails 5.2.3 + Ruby 2.5.1, but breaks in staging where we have Puma. What’s the issue here? When to expect a fix?
What is the current recommendation for this issue? @eregon said this should be closed, but we continue to see reports of this in 2.3 and 2.4, and the issue is still open. Is there a recommended workaround?
It continued to be an issue for me with
sassc-2.3.0, and @paulschreiber indicated that it continued to be a problem withsassc-2.4.0. In both cases it was being pulled in as a dependency forffi.Nevetherless:
gem uninstall sassc
gem install sassc – --disable-march-tune-native
Fixes the issue in OSX
I am running Fedora 30 also and I have the same bug. But I found a workaround:
libsass.soin my~/.gem/ruby/gems/withfindcommandlibsass.sois located in different directory than expectedthis should be enough then also for you:
cd ~/.gem/ruby/gems/sassc-2.2.0/lib/sassc/ && ln -s ../../ext/libsass.so .and later you will probably need it in your jekyll site directory too, if you have gems saved locally in
vendor/bundle/directory:cd vendor/bundle/ruby/2.6.0/gems/sassc-2.2.0/lib/sassc && ln -s ../../ext/libsass.so .Updating to 2.3.0 resolved lib/sassc/engine.rb:42: [BUG] Illegal instruction at …
For me on Azure with Docker, image ruby:2.4.4
Hey guy, could you use
<details></details>to wrap your answer? It looks a bit too long.@ogabriel are you caching your gems? If so what happens if you use my previous recommendation with no cache?
So far the ONLY thing that has worked for me is to downgrade the
sasscgem to version2.1.0:This is my stack:
ruby:2.6.5-busterThanks @alex-mohemian. I somehow missed it, but I think a solution a couple fo comments down (applying some small tweaks) seems to work, essentially adding this to our Dockerfile
Is this the “proper” solution though, or just a workaround? I hope sassc-ruby fixes this, but have no clue what’s involved to be honest…
I’m having the same issue on OSX 10.14.6 with ruby 2.5.6p201.
having the same issue, lead us to revert the update: https://github.com/openSUSE/open-build-service/pull/8250
Backtrace: https://gist.github.com/vpereira/46ec18afdf1bbde20438c9933dbb1ec3
The issue is still present 😦
steal crash
@dmitry I resolved the issue and updated my original comment with details. Thanks for asking.
Configuring the Gemfile to use the last sassc commit solved the Mac OS X error (malformed mach-o image: dylib load command #10 string extends beyond end of load command) for me:
gem 'sassc', :git => 'git@github.com:sass/sassc-ruby.git'@Moriort your gcc 4.4 is too old, you need to upgrade to GCC 4.7+ https://github.com/sass/libsass/blob/b894c529b8caf6c31f9206953e180e79b80cf97a/Readme.md#building
@oehlschl if you’re using CodeBuild the latest version will be compiled to the instruction set used by the CPU in CodeBuild (not sure what instance types are used) and if you then try to run the image on another instance that uses a different CPU you’ll get this error.
This worked for me, thanks!
what solved for me was to do the following:
before installing the gem
@alex-mohemian so theoretically adding
RUN bundle config --local build.sassc --without-march-tune-nativebeforebundle installin Dockerfile should solve this issue. But it doesn’t, any thoughts?bundle config in docker image:
@alex-mohemian same context, thanks for the solution.
@glebm @bolandrm can we disable -tune=native by default ?
Same error on Centos 7.
Ha, yeah the main problem in my case was that I could compile the assets and everything in codefresh but in the deploy the pods crashed by the
Illegal instructionFor the downgrade I had to add libc6-compat, libsass libsass-dev and
ENV LD_LIBRARY_PATH=/lib64Here’s my entire Dockerfile: