Error: /lib64/libz.so.1: version `ZLIB_1.2.9' not found (required by /opt/nodejs/node_modules/canvas/build/Release/libpng16.so.16)

[JeffersonSchuler]

When running on AWS Lambda using Node 14 with Canvas v2.7.0 I am seeing the following error:

Error: /lib64/libz.so.1: version `ZLIB_1.2.9' not found (required by /opt/nodejs/node_modules/canvas/build/Release/libpng16.so.16)

I am successfully running on Node 14 using Canvas v2.6.1, but wanted to upgrade. This library is a dependency of ChartjsNodeCanvas which is ultimately what I am calling.

Thanks.

[adamsoffer]

Getting the same error running on Vercel Node 14 :/

[jaggr2]

I made some tests:

• Canvas v2.7.0 is working on AWS Lambda Node 12, but not 14
• It fails even when canvas is the only and first dependency in the lambda handler script, so the shared zlib dependency is preloaded by something else.
• NodeJS 12 and 14 on AWS Lambda are using zlib version 1.2.11 according to console.log(process.version) . But I guess zlib is compiled directly into NodeJS and is not using the shared library, so this does not matter
• I tried to inject the correct libz.so.1 via a lambda layer in /lib64 path, but without any success yet. The LD_LIBRARY_PATH environment variable on my lambda has following value "LD_LIBRARY_PATH": "/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/opt/lib", While listing the /lib64 directory I noticed that there is a libz.so.1.2.7 as well, but I don't know from where this one comes from.

[JeffersonSchuler]

I had also tried to inject the correct zlib version with no luck. Will circle back when I have some time. At this moment, Canvas v2.6.1 is working fine for me.

[charoitel]

I built Canvas v2.8.0 from source on Amazon Linux 2, and now published the packaged layer on AWS Serverless Application Repository (https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:990551184979:applications~lambda-layer-canvas-nodejs). Hope this layer could help.

[alvarlagerlof]

I've got the same issue running on Vercel

[mraerino]

this seems to happen based on LD_LIBRARY_PATH set. in AWS lambda it is /lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib

there is a libz.so.1 in /lib64 so although canvas includes a libz.so.1 the one from the OS gets loaded first.

two possible solutions:

• add /var/task/node_modules/canvas/build/Release to the beginning of LD_LIBRARY_PATH
• set LD_PRELOAD=/var/task/node_modules/canvas/build/Release/libz.so.1

to properly fix this in canvas i think the libs linking to libz should ensure they can differentiate, e.g. by linking against .1.2.9 directly instead of just .1 or by using static linking.

[ludovicraymond]

this seems to happen based on LD_LIBRARY_PATH set. in AWS lambda it is /lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib

there is a libz.so.1 in /lib64 so although canvas includes a libz.so.1 the one from the OS gets loaded first.

two possible solutions:

• add /var/task/node_modules/canvas/build/Release to the beginning of LD_LIBRARY_PATH
• set LD_PRELOAD=/var/task/node_modules/canvas/build/Release/libz.so.1

to properly fix this in canvas i think the libs linking to libz should ensure they can differentiate, e.g. by linking against .1.2.9 directly instead of just .1 or by using static linking.

set LD_PRELOAD works for me !

[alvarlagerlof]

set LD_PRELOAD works for me !

How do I do this in Vercel?

[kagawagao]

set LD_PRELOAD works for me !

How do I do this in Vercel?

as @JeffersonSchuler said, use canvas@2.6.1, it worked for me

[mraerino]

as @JeffersonSchuler said, use canvas@2.6.1, it worked for me

didn't work for me on AWS lambda with nodejs14.x

[JeffersonSchuler]

as @JeffersonSchuler said, use canvas@2.6.1, it worked for me

didn't work for me on AWS lambda with nodejs14.x

I am using it in a Layer, not sure if it makes a difference.

[ludovicraymond]

@mraerino

The solution that works on Lambda with node 14.x and canvas@2.8.0 :

• Create an EC2 compatible with Lambda (I have used the AMI amzn-ami-hvm-2018.03.0.20181129-x86_64-gp2)
• Install node 14, install your packages with npm for example, download your packages (node_modules) with tar & scp for example and use them for your lambda function deployment.
• Add a layer on your lambda function (I used the lib64 version) : https://github.com/jwerre/node-canvas-lambda
• Define an environment variable : LD_PRELOAD=/var/task/node_modules/canvas/build/Release/libz.so.1

That's it !

[mraerino]

When deploying through Netlify I was able to just install regularly through npm and didn't need a special layer, but customized the LD_LIBRARY_PATH

[JeffersonSchuler]

I built Canvas v2.8.0 from source on Amazon Linux 2, and now published the packaged layer on AWS Serverless Application Repository (https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:990551184979:applications~lambda-layer-canvas-nodejs). Hope this layer could help.

Thanks for doing the layer, this worked for me. I was already using a layer for some of the bigger packages like canvas and did not want to package them into the main function deployment. I tried the two environment variable solutions suggested here with no luck.

[jacobdubail]

set LD_PRELOAD works for me !

How do I do this in Vercel?

Did you figure this out? I'm stuck.

[andrewbarnesweb]

How do I do this in Vercel?

Not sure if it helps, if you need the latest features, but as above. Sorted it for me on Vercel by using canvas@2.6.1.

[jacobdubail]

set LD_PRELOAD works for me !

How do I do this in Vercel?

Did you figure this out? I'm stuck.

The issue was fabric. It includes an outdated version of jsdom, which references canvas 2.5.0. I'm using fabric-pure-browser now, which removes the canvas dependency.

[nikmish1]

I've got the same issue running on Vercel

Hi, were you able to resolve it. I am trying to run worpress starter with some custom pages. But getting the above error though everything runs well locally.

[nikmish1]

this seems to happen based on LD_LIBRARY_PATH set. in AWS lambda it is /lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib

there is a libz.so.1 in /lib64 so although canvas includes a libz.so.1 the one from the OS gets loaded first.

two possible solutions:

• add /var/task/node_modules/canvas/build/Release to the beginning of LD_LIBRARY_PATH
• set LD_PRELOAD=/var/task/node_modules/canvas/build/Release/libz.so.1

to properly fix this in canvas i think the libs linking to libz should ensure they can differentiate, e.g. by linking against .1.2.9 directly instead of just .1 or by using static linking.

adding LD_LIBRARY_PATH=/var/task/node_modules/canvas/build/Release worked for me. Thanks

[paulschneider]

How do I do this in Vercel?

Not sure if it helps, if you need the latest features, but as above. Sorted it for me on Vercel by using canvas@2.6.1.

Not related to Vercel but using Canvas in Node14 we experienced this same problem on our build server; downgrading to 2.61 resolved the issue for us.

[SimplyLinn]

For people wanting this on Vercel. Due to Iterative Static Regeneration and the dynamic loading you can get with Vercel in general, you need to set LD_LIBRARY_PATH properly for all instances of the Vercel processes that are spawned, not just the initial buildscript.

// For building on vercel: https://github.com/Automattic/node-canvas/issues/1779
if (
  process.env.LD_LIBRARY_PATH == null ||
  !process.env.LD_LIBRARY_PATH.includes(
    `${process.env.PWD}/node_modules/canvas/build/Release:`,
  )
) {
  process.env.LD_LIBRARY_PATH = `${
    process.env.PWD
  }/node_modules/canvas/build/Release:${process.env.LD_LIBRARY_PATH || ''}`;
}

Adding this to the top of next.config.js made Vercel build the project for me, and it will hopefully carry over to any processes spawned in the future that also has to load next.config.js.

[arrokh]

For people wanting this on Vercel. Due to Iterative Static Regeneration and the dynamic loading you can get with Vercel in general, you need to set LD_LIBRARY_PATH properly for all instances of the Vercel processes that are spawned, not just the initial buildscript.

// For building on vercel: https://github.com/Automattic/node-canvas/issues/1779
if (
  process.env.LD_LIBRARY_PATH == null ||
  !process.env.LD_LIBRARY_PATH.includes(
    `${process.env.PWD}/node_modules/canvas/build/Release:`,
  )
) {
  process.env.LD_LIBRARY_PATH = `${
    process.env.PWD
  }/node_modules/canvas/build/Release:${process.env.LD_LIBRARY_PATH || ''}`;
}

Adding this to the top of next.config.js made Vercel build the project for me, and it will hopefully carry over to any processes spawned in the future that also has to load next.config.js.

I can't believe, it perfectly works. Thank you so much @SimplyLinn

[BrunoQuaresma]

@SimplyLinn and @arrokh what "now-build" script are you using? The proposed solution for Vercel didn't work for me 😥

I'm still seeing the following error:

ERROR   Error: /lib64/libz.so.1: version `ZLIB_1.2.9' not found (required by /var/task/node_modules/canvas/build/Release/libpng16.so.16)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1144:18)

and the "now-build" script that I'm using is:

{
  ...
  "now-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/ && npm run build"
}

I'm using "canvas": "^2.7.0" and NodeJS 14.

[SimplyLinn]

@SimplyLinn and @arrokh what "now-build" script are you using? The proposed solution for Vercel didn't work for me 😥

I'm still seeing the following error:

ERROR Error: /lib64/libz.so.1: version `ZLIB_1.2.9' not found (required by /var/task/node_modules/canvas/build/Release/libpng16.so.16)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1144:18)

and the "now-build" script that I'm using is:

{
  ...
  "now-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/ && npm run build"
}

I'm using "canvas": "^2.7.0" and NodeJS 14.

Using canvas@^2.8.0. package.json

{
    "build": "yarn bootstrap && next build",
    "bootstrap": "run-p -l --silent --aggregate-output bootstrap:*",
    "bootstrap:robots-txt": "NODE_ENV=production node bootstrap-robots.js",
}

The bootstrap process is just doing some robots.txt schenanigans based on stuff and places it in the public folder and has little to do with the canvas library

Install command override configured in vercel: yarn install --production="false" && rm -f node_modules/canvas/build/Release/librsvg-2.so.2 (We do not need svg support for our uses, and librsvg was over 100mb and made our bundle approach the size limit of vercel)

Since you were using canvas@^2.7.0, I'd suggest you try latest version of canvas maybe? Otherwise I'm out of advice.

[robbennet]

For people wanting this on Vercel. Due to Iterative Static Regeneration and the dynamic loading you can get with Vercel in general, you need to set LD_LIBRARY_PATH properly for all instances of the Vercel processes that are spawned, not just the initial buildscript.

// For building on vercel: https://github.com/Automattic/node-canvas/issues/1779
if (
  process.env.LD_LIBRARY_PATH == null ||
  !process.env.LD_LIBRARY_PATH.includes(
    `${process.env.PWD}/node_modules/canvas/build/Release:`,
  )
) {
  process.env.LD_LIBRARY_PATH = `${
    process.env.PWD
  }/node_modules/canvas/build/Release:${process.env.LD_LIBRARY_PATH || ''}`;
}

Adding this to the top of next.config.js made Vercel build the project for me, and it will hopefully carry over to any processes spawned in the future that also has to load next.config.js.

I can't believe, it perfectly works. Thank you so much @SimplyLinn

Can confirm this works for me on Vercel

[htr3n]

After many times trying to make node canvas work with AWS Lambda Node.js 14.x, I've justfigured out using container can address the problem with missing libraries. I wrote up an article here: https://medium.com/@htr3n/building-node-canvas-container-for-aws-lambda-a3b732aa48c0. An example project is here: https://github.com/htr3n/node-canvas-lambda-container

[colbyfayock]

set LD_PRELOAD works for me !

How do I do this in Vercel?

Did you figure this out? I'm stuck.

The issue was fabric. It includes an outdated version of jsdom, which references canvas 2.5.0. I'm using fabric-pure-browser now, which removes the canvas dependency.

Using fabric-pure-browser + manually installing jdom and canvas@2.6.1 worked for me here: https://github.com/colbyfayock/next-wordpress-starter/pull/266

[far0s]

Hi, I've encountered a similar issue, here is the error message I get in my Vercel logs:

ERROR   Error: librsvg-2.so.2: cannot open shared object file: No such file or directory
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1131:18)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)
    at Module.require (internal/modules/cjs/loader.js:961:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at Object.<anonymous> (/var/task/node_modules/canvas/lib/bindings.js:3:18)
    at Module._compile (internal/modules/cjs/loader.js:1072:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)

I don't even use librsvg, and I'd be happy to remove it from my build entirely (like @SimplyLinn did), but I'm not sure how to fix this. I have tried many of the solutions mentioned in this thread (changing my package.json, next.config.js, adding env variables in the Vercel admin, etc.).

I'm wondering if librsvg-2.so.2 should be bundled with yum install libuuid-devel libmount-devel zlib && cp /lib64/{libuuid,libmount,libblkid,libz}.so.1 node_modules/canvas/build/Release/ but I'm not familiar with yum and any of those packages so not sure what I'm looking at here.

Setup:

• Next.js 12.0.2
• canvas 2.8.0 (tried downgrading to 2.6.1 but I'm getting annoying node-gyp errors so I gave up on that for now)
• Not using canvas for anything else but one createCanvas() call in a /pages/api file

[scott-schibli]

Hi, I've encountered a similar issue, here is the error message I get in my Vercel logs:

ERROR Error: librsvg-2.so.2: cannot open shared object file: No such file or directory
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1131:18)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)
    at Module.require (internal/modules/cjs/loader.js:961:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at Object.<anonymous> (/var/task/node_modules/canvas/lib/bindings.js:3:18)
    at Module._compile (internal/modules/cjs/loader.js:1072:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)

I don't even use librsvg, and I'd be happy to remove it from my build entirely (like @SimplyLinn did), but I'm not sure how to fix this. I have tried many of the solutions mentioned in this thread (changing my package.json, next.config.js, adding env variables in the Vercel admin, etc.).

I'm wondering if librsvg-2.so.2 should be bundled with yum install libuuid-devel libmount-devel zlib && cp /lib64/{libuuid,libmount,libblkid,libz}.so.1 node_modules/canvas/build/Release/ but I'm not familiar with yum and any of those packages so not sure what I'm looking at here.

Setup:

• Next.js 12.0.2
• canvas 2.8.0 (tried downgrading to 2.6.1 but I'm getting annoying node-gyp errors so I gave up on that for now)
• Not using canvas for anything else but one createCanvas() call in a /pages/api file

I am in the exact same boat. Did you find a solution?

[far0s]

@scott-schibli I haven't, this is on a small side-project so I was not in a hurry to get it fixed. Although I would love to hear some guidance or info on how I can avoid this error!

[GMaiolo]

@scott-schibli @Far0s I'm in the exact same boat, hope someone solves it eventually

[jackguoAtJogg]

For people wanting this on Vercel. Due to Iterative Static Regeneration and the dynamic loading you can get with Vercel in general, you need to set LD_LIBRARY_PATH properly for all instances of the Vercel processes that are spawned, not just the initial buildscript.

// For building on vercel: https://github.com/Automattic/node-canvas/issues/1779
if (
  process.env.LD_LIBRARY_PATH == null ||
  !process.env.LD_LIBRARY_PATH.includes(
    `${process.env.PWD}/node_modules/canvas/build/Release:`,
  )
) {
  process.env.LD_LIBRARY_PATH = `${
    process.env.PWD
  }/node_modules/canvas/build/Release:${process.env.LD_LIBRARY_PATH || ''}`;
}

Adding this to the top of next.config.js made Vercel build the project for me, and it will hopefully carry over to any processes spawned in the future that also has to load next.config.js.

I can't believe, it perfectly works. Thank you so much @SimplyLinn

This worked for me!!

[fsobh]

this seems to happen based on LD_LIBRARY_PATH set. in AWS lambda it is /lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib

there is a libz.so.1 in /lib64 so although canvas includes a libz.so.1 the one from the OS gets loaded first.

two possible solutions:

* add `/var/task/node_modules/canvas/build/Release` to the beginning of `LD_LIBRARY_PATH`

* set `LD_PRELOAD=/var/task/node_modules/canvas/build/Release/libz.so.1`

to properly fix this in canvas i think the libs linking to libz should ensure they can differentiate, e.g. by linking against .1.2.9 directly instead of just .1 or by using static linking.

This Worked Perfectly for me. Just go to your lambda in your AWS console, click on configuration > Env Variables and just add it

[AdriaFret]

For me using Lambda function with Serverless Framework and nodejs12.x the next steps solved the problem:

• Follow installation instructions for AWS in the node-canvas repository NOTE: If your Lambda function has more dependencies i would recommend you to upload the package.json to ec2 and then compile all the dependencies in the ec2 machine (npm i)
• Then inside your project folder replace the node_modules folder with the one you created on the ec2 instance.
• Add the precompiled lib folder(also created in ec2) to the project folder. NOTE: This can also be added to the Lambda function using a layer but its not mandatory
• Last add enviroment variable. LD_PRELOAD: "/var/task/node_modules/canvas/build/Release/libz.so.1" to the project.
• Make sure that when deploying to the Lambda function there is no npm install, npm i or npm ci... because what the Lambda needs to work is the precompiled node_modules folder and that would overwrite it.

Project structure example:

-+project_folder --+folder_x --+folder_y --+lib --+node_modules

Hope it helps! :)

[VenkateshMogili]

this seems to happen based on LD_LIBRARY_PATH set. in AWS lambda it is /lib64:/usr/lib64:$LAMBDA_RUNTIME_DIR:$LAMBDA_RUNTIME_DIR/lib:$LAMBDA_TASK_ROOT:$LAMBDA_TASK_ROOT/lib:/opt/lib

there is a libz.so.1 in /lib64 so although canvas includes a libz.so.1 the one from the OS gets loaded first.

two possible solutions:

• add /var/task/node_modules/canvas/build/Release to the beginning of LD_LIBRARY_PATH
• set LD_PRELOAD=/var/task/node_modules/canvas/build/Release/libz.so.1

to properly fix this in canvas i think the libs linking to libz should ensure they can differentiate, e.g. by linking against .1.2.9 directly instead of just .1 or by using static linking.

1. Downloaded the lib files: https://github.com/jwerre/node-canvas-lambda/blob/master/node12_canvas_lib64_layer.zip
2. Extracted and kept the folder in the project root directory.
3. Added "now-build": "cp node12_canvas_lib64_layer/lib/*so.1 node_modules/canvas/build/Release/" in scripts.
4. Added LD_LIBRARY_PATH /var/task/node_modules/canvas/build/Release environment variable in vercel project settings.
5. LD_PRELOAD is giving another issue, so I removed it and tested.

It's working fine for me.

[far0s]

@VenkateshMogili tried this, deployment fails after your cp command, returns this error:

Error: The file "/vercel/path0/.next/routes-manifest.json" couldn't be found. This is normally caused by a misconfiguration in your project.

I'd be curious to see your larger setup here.

[FelipeSantos92Dev]

For people wanting this on Vercel. Due to Iterative Static Regeneration and the dynamic loading you can get with Vercel in general, you need to set LD_LIBRARY_PATH properly for all instances of the Vercel processes that are spawned, not just the initial buildscript.

// For building on vercel: https://github.com/Automattic/node-canvas/issues/1779
if (
  process.env.LD_LIBRARY_PATH == null ||
  !process.env.LD_LIBRARY_PATH.includes(
    `${process.env.PWD}/node_modules/canvas/build/Release:`,
  )
) {
  process.env.LD_LIBRARY_PATH = `${
    process.env.PWD
  }/node_modules/canvas/build/Release:${process.env.LD_LIBRARY_PATH || ''}`;
}

Adding this to the top of next.config.js made Vercel build the project for me, and it will hopefully carry over to any processes spawned in the future that also has to load next.config.js.

Thak you, so much! The only way to make it work!

[henrybabbage]

I was unable to deploy to Vercel unfortunately despite following the above advice. Interestingly when I used the next.config snippet this did give me a successful deployment (clearing the "Error: /lib64/libz.so.1: version `ZLIB_1.2.9' not found" error) however my deployed site had no pages and displayed only 500 – page not found errors.

Did anyone find another solution?

[moarsel]

I tried all pretty much every suggestion in this thread (and this one, and this one) and none worked for my vercel deployment with canvas and fabricjs.

Sometimes I would get it to build but the serverless functions were still failing looking for with zlib 1.2.9 or libuuid. But I finally found a package.json configuration that worked for me: downgrading canvas to 2.6.1 and reinstalling all its dependencies.

"scripts": {
    "canvas:fix": "yum install gcc-c++ cairo-devel pango-devel libjpeg-turbo-devel giflib-devel libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/",
    "vercel-build": "npm run canvas:fix && npm run build"
},
"dependencies": { 
...
   "canvas": "=2.6.1",
    "fabric": "^4.0.0",
...
}

It's a gnarly issue, hope this helps someone!

[ohager]

For Vercel (Node14) this works for me:

In package.json

  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "export": "next build && next export",
    ...
    "vercel-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/"
  },
  "dependencies": {
     ...
      "canvas": "2.6.1",
      ...
  }

According to this I edited my next.config.js and in Vercel I selected Next.js preset and override as follows

[iamdagy]

When deploying through Netlify I was able to just install regularly through npm and didn't need a special layer, but customized the LD_LIBRARY_PATH

What value did you use? what build command did you set? thanks

[erran]

I managed to get things working after adding a tweak to the vercel-build script documented at https://github.com/jeetiss/vercel-canvas (e.g. adding && next build):

-"vercel-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/"
+"vercel-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/ && next build"

Adding LD_LIBRARY_PATH to my project's environment variables on Vercel as /var/task/node_modules/canvas/build/Release:$LD_LIBRARY_PATH.

I confirmed canvas versions 2.9.0 and 2.9.1 worked with either Node 14 or 16 with the specific vercel-build command and environment variable set .

[jlarmstrongiv]

Unfortunately, installing all of those libraries makes the build take quite a bit longer.

For Vercel specifically, I ended up using:

mkdir -p "/var/task/node_modules/canvas/build/Release"
cp -R "/vercel/path0/node_modules/canvas/build/Release/." "/var/task/node_modules/canvas/build/Release/"
export LD_PRELOAD="/var/task/node_modules/canvas/build/Release/libz.so.1"
export LD_LIBRARY_PATH="/var/task/node_modules/canvas/build/Release:/var/lang/lib:/lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/opt/lib"

That said, I’m using a build-time dependency, not a runtime dependency, so this solution may or may not work for you.

[far0s]

Thanks @erran, your solution worked for on Node 16 with canvas v2.9.1 😄

[HereFrank]

I managed to get things working after adding a tweak to the vercel-build script documented at https://github.com/jeetiss/vercel-canvas (e.g. adding && next build):

-"vercel-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/"
+"vercel-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/ && next build"

Adding LD_LIBRARY_PATH to my project's environment variables on Vercel as /var/task/node_modules/canvas/build/Release:$LD_LIBRARY_PATH.

I confirmed canvas versions 2.9.0 and 2.9.1 worked with either Node 14 or 16 with the specific vercel-build command and environment variable set .

These works for me too!! Thanks!

[lukasfischer]

For folks who are looking for a solution to get it running on Vercel, Node 16, latest canvas – @erran helped with https://github.com/Automattic/node-canvas/issues/1779#issuecomment-1153851816.

This was my solution:

1. Add this to your package.json under scripts: "vercel-build": "yum install libuuid-devel libmount-devel && cp /lib64/{libuuid,libmount,libblkid}.so.1 node_modules/canvas/build/Release/ && next build"

2. An env variable in Vercel LD_LIBRARY_PATH /var/task/node_modules/canvas/build/Release:$LD_LIBRARY_PATH

3. configure build command like this

[rlods]

To solve the issue with last version of Vercel and canvas:

in package.json

"scripts": {
    "build": "./setup.sh && next build"
 }

and create setup.sh

yum install wget

wget https://github.com/NixOS/patchelf/archive/refs/tags/0.17.0.tar.gz
tar -xf 0.17.0.tar.gz
cd patchelf-0.17.0
./bootstrap.sh
./configure
make
make install
cd ..

wget https://zlib.net/fossils/zlib-1.2.9.tar.gz
tar -xf zlib-1.2.9.tar.gz
cd zlib-1.2.9
sh configure
make
cp libz.so.1.2.9 ../node_modules/canvas/build/Release/libz.so.X
cd ..

patchelf --replace-needed /lib64/libz.so.1 libz.so.X ./node_modules/canvas/build/Release/libpng16.so.16
patchelf --replace-needed libz.so.1 libz.so.X ./node_modules/canvas/build/Release/libpng16.so.16

[arioberek]

@erran solution worked for me Node v16.18.1 node-canvas: 2.10.2

[gward35]

I'm having the same problem but I dont have a next app. Its an express app that uses canvas on the server to be piped to the frontend. Following the steps listed here sans next build I now get the following error.

ERROR Error: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /var/task/node_modules/canvas/build/Release/libglib-2.0.so.0)

Have tired using node14/16 and the latest canvas (2.10.2)

The app works locally

[SyedHammad06]

I am using Nextjs + fabricjs. This is what worked for me.

uninstall fabricjs

npm i fabric-pure-browser npm i jsdom

feel free to clone my repo: https://github.com/SyedHammad06/fabricjs.git