Working on the `GLIBC_2.25 not found` build issue

[avsthiago]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[avsthiago]

Hi @xhochy, @janjagusch, and @jtilly,

I'm addressing a build issue in our conda feedstock (link to build issue) due to CentOS 7's outdated GLIBC conflicting with Node 18 requirements.

Since code-server doesn't support cos7 anymore, would building the package on a different Linux distribution with a newer GLIBC be a feasible workaround in the conda-forge context? Any guidance or alternative suggestions would be greatly appreciated

+ code-server --help
node:internal/modules/cjs/loader:1340
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /home/conda/feedstock_root/build_artifacts/code-server_1701001419227/_h_env_placehold/share/code-server/node_modules/argon2/lib/binding/napi-v3/argon2.node)
    at Module._extensions..node (node:internal/modules/cjs/loader:1340:18)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12)
    at Module.require (node:internal/modules/cjs/loader:1143:19)
    at require (node:internal/modules/cjs/helpers:119:18)
    at Object.<anonymous> (/home/conda/feedstock_root/build_artifacts/code-server_1701001419227/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/share/code-server/node_modules/argon2/argon2.js:9:25)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12) {
  code: 'ERR_DLOPEN_FAILED'

[xhochy]

At the moment, it's not possible.

[avsthiago]

@xhochy, what do you think about this solution? I kept the code-server --help test for the osx and aarch64 and reduced the test to only which code-server when building the linux64 version.

My goal here is to unblock the osx and aarch64 builds. I also expect the package to only fail on Linux only if the system doesn't have GLIBC >= 2.25.

[avsthiago]

@xhochy, could you please review this PR again when you have time?

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[xhochy]

@conda-forge-admin please rerender

[avsthiago]

@conda-forge-admin please rerender

[ehfd]

@avsthiago Unfortunately, c_stdlib as sysroot was probably not it. After rerender, that was automatically fixed and logs changed to something else.

Perhaps the build container to Alma (within conda_build_config.yaml)?

[avsthiago]

Yeah, @ehfd, that didn't work. I'll give it another try with the Alma image.

[avsthiago]

@conda-forge-admin please rerender

[ehfd]

Looks like the original solutions were right, except needing to rerender after putting it into conda_build_config.yaml.

[avsthiago]

@xhochy I tried to fix the build by only changing the c_stdlib_version, but that didn't work. The only fix I found so far was to change the docker_image.

Do you see any other option?

[ehfd]

I guess changing docker_image for conda_build_config.yaml and rerendering is OK, if not changing the .scripts folder?

[xhochy]

c_stdlib_version is the way to go. What was the error?

Otherwise the version constraints will not be set correctly.

[ehfd]

@xhochy

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=917329&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=986b1512-c876-5f92-0d81-ba851554a0a3

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=917329&view=logs&jobId=6494c7a6-a019-59a3-6f3d-9bab8ca96717&j=6494c7a6-a019-59a3-6f3d-9bab8ca96717&t=18c91bca-a25a-5f89-34d4-93bbec4021bc

Compare the two. linux_64 still shows Error: /lib64/libc.so.6: versionGLIBC_2.25' not found` for testing. Build is successful, but cannot test.

[ehfd]

@avsthiago @xhochy Perhaps require stdlib('c') with 2.28 constraint in the test environment as well? It can be that the test environment is capturing the container (outside) glibc environment. Otherwise, when sysroot is 2.28 the build container must change automatically to Alma 8.

[xhochy]

We probably need the docker image and c_stdlib_version at the same time. In future, setting the docker image should be obsolete, but until the new sysroot is fully rolled out, we will need to add that to conda_build_config.yaml, too.

[ehfd]

@xhochy Then everything is as it is now.

https://github.com/conda-forge/code-server-feedstock/pull/95/commits/24af81eceedc84ecd78f704a39f0f8de23c4f875