We currently using the .ToCSS function to compile the SASS located in the assets folder, and it has been working great for us, until we reached our AWS lambdas.
We are trying to run Hugo (extended version) in an AWS lambda, but seems to have an issue when we try to let Hugo compile our sass, Lambda throws the following error:
/tmp/bin/hugo: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/bin/hugo)
/tmp/bin/hugo: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /tmp/bin/hugo)
Do you have any idea if it’s possible to have Hugo compile SASS in an AWS Lambda context?
Another option is to build your site locally with Hugo extended and then commit the resources dir (which includes a cache of your CSS). Then AWS Lambda would be able to build your site using Hugo non-extended
It should be a very recent version of Linux. It seems to be the c++ that isn’t supported on AWS Lambda out of the box.
Hmm, the suggestion with including the resources dir looks like a possible solution. I’m not sure how that would handle cache busting though. Guess we have to try it, i must admit it looks like a potential solution.
Right now we’re looking at AWS Lambda Layers, and if it is possible to use that to add the c++ support. I will report it here if it works.
We got Hugo (non-extended) running fine in Lambda, and also tried bundling the libstdc++.so.6 with Hugo binary but it kept looking for it in usr/lib64, even though the new location is in LD_LIBRARY_PATH. We might abandon the cause of getting Hugo extended running in AWS Lambda and revert to building Sass locally and then commit it.