postlink failed on linux: libXi.so.6 cannot open shared object file

[bollwyvl]

Over on https://github.com/conda-forge/firefox-feedstock/pull/18 we're trying to get gtk3 in there to maybe resolve some issues. On linux, we're seeing this error:

conda.CondaMultiError: post-link script failed for package conda-forge::gtk3-3.24.21-h45fd312_1
location of failed script: /home/conda/feedstock_root/build_artifacts/firefox_1596135386472/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/bin/.gtk3-post-link.sh
==> script messages <==
<None>
==> script output <==
stdout: 
stderr: /home/conda/feedstock_root/build_artifacts/firefox_1596135386472/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/bin/gtk-query-immodules-3.0: error while loading shared libraries: libXi.so.6: cannot open shared object file: No such file or directory

return code: 127

()

This was opened back in may, though i was having issues get those logs, can't say whether it was the same issue then.

I'll post more as i debug stuff...

[ryanvolz]

I'd guess this error hearkens back to #7. gtk3 depends on the X11 CDTs, but those don't make the necessary libraries available during the testing phase, thus the missing libXi.so.6. Adding a yum_requirements.txt like https://github.com/conda-forge/gtk3-feedstock/blob/master/recipe/yum_requirements.txt should fix that.

[bollwyvl]

nice, i'll give it a shot! maybe a link to that issue could be added to the postlink?

[johnlees]

Perhaps due to: https://github.com/conda-forge/docker-images/commit/f598f6e92890a9afbba8984911fbfb4752882c1e#diff-eaf90fc2058811bb1d22f2204a4775a8?

[ryanvolz]

Perhaps due to: conda-forge/docker-images@f598f6e#diff-eaf90fc2058811bb1d22f2204a4775a8?

It's an intended behavior with CDTs; they are dependencies that are supposed to be supplied by the user's system. The test phase of the CI build is one such user, and it so happens that that user system does not have X11 installed unless you tell it to with yum_requirements.txt. See https://conda-forge.org/docs/maintainer/knowledge_base.html#libgl which gives the example case of libgl but equally applies here.

I agree that this is messy and annoying, and even knowing about it, it bites me frequently when making new packages. That's why it would be good for us to resolve #7, and this issue coming up again here lends evidence in favor of dumping CDTs and using the native conda-forge Xorg packages.

[bollwyvl]

Update here: going to cos7 and yum_requirementing all my stuff (including gtk3 :cry: , for now, as i lack the patchelf kung-fu to fix the monster that is firefox) has let me get to a testable state.

I'd love to get a real, end-to-end source build working, but that's pretty infeasible until we have a better build cache, which i think might be coming.

So for my purposes, I'm happy to close this, but if it's useful to keep it open for the SEO juice, that's fine, too.

[ryanvolz]

I think we can leave it open for visibility until we make it less likely for this to come up with gtk3 in the test phase of recipes.

[mbargull]

Is there anything specific to the user's environment that affects https://github.com/conda-forge/gtk3-feedstock/blob/bc3fb948e90e3f209063dbda69e7a4231a39eade/recipe/post-link.sh#L1-L3 ? If not, it would be best if those commands could be run as part of this package's build.

[tschoonj]

It is very important that these commands are run as part of a post-link step, and not as a part of the build: lots of recipes may need to update the files these commands create.

[mbargull]

lots of recipes may need to update the files these commands create.

Can you give examples of such recipes? How does this work? If you have a file that is in $PREFIX (installed normally or in a post-link step) then changes to that file will not be packaged anyway. So, I don't understand what the difference would be to package those files upfront as opposed to running a post-link script.

[tschoonj]

Hmmm, I cannot find a recipe where these commands also need to be executed, but this may only be a matter of time. For example, in Homebrew, there are many formulas where they are required. As soon as someone adds one of these packages to conda-forge, the commands would need to go into a post-link step. In fact, without this, there would be build issues when trying to add such a package in staged-recipes.

An example: glib-compile-schemas creates a file $PREFIX/share/glib-2.0/schemas/gschemas.compiled, based on the current contents of that folder. However, multiple packages may contribute multiple files to this folder, so if this command were run as part of the build, it will be a reflection of what was in that folder during the build only, which may break other software. If another conda-forge package would need to run this command during the build, it would also produce this same file, and there will be a conflict at installation time if gtk3 is already in there.

[mbargull]

@tschoonj, thanks for the detailed explanation, makes sense!

[falcorocks]

Hi all, I run into this problem when trying: conda install -c conda-forge graph-tool within the docker image of continuumio/miniconda3.

As advised, my solution is to install manually the content of the https://github.com/conda-forge/gtk3-feedstock/blob/master/recipe/yum_requirements.txt

[hmaarrfk]

has anybody found the minimum requirements for ubuntu?

[chrisburr]

Passing by from conda-forge/staged-recipes#14567 without having read the discussion fully but would it be practical to allow the commands to fail in a similar to how gdk-pixbuf handles this? As it stands it's impossible to create environments for different platforms than the current host.

[ryanvolz]

Passing by from conda-forge/staged-recipes#14567 without having read the discussion fully but would it be practical to allow the commands to fail in a similar to how gdk-pixbuf handles this? As it stands it's impossible to create environments for different platforms than the current host.

Yes, that is a good improvement.

This also brings up the X11 CDT dependencies; I think the case has been built through these numerous headaches to drop them in favor of the conda-forge xorg packages, and we've already taken that plunge with gtk4. That discussion should continue over at #7, so anyone with a stake should join me there.