With pixi, tests link to pinocchio in `.pixi/envs` folder

[abussy-aldebaran]

Bug description

When using pixi to build pinocchio, after a ninja install, tests link with pinocchio's libs that are installed in .pixi/envs/....

Expected behavior

When using pixi to build pinocchio, after a ninja install, tests link with pinocchio's libs that are in the build tree.

Reproduction steps

Steps to reproduce the behavior:

pixi run configure
pixi shell
cd build
ninja
ldd unittest/pinocchio-test-cpp-model | grep pinocchio_default
	libpinocchio_default.so.3.4.0 => /home/antoine.bussy/work/pinocchio/build/src/libpinocchio_default.so.3.4.0 (0x00007b8be4e00000)
ninja install
ldd unittest/pinocchio-test-cpp-model | grep pinocchio_default
	libpinocchio_default.so.3.4.0 => /home/antoine.bussy/work/pinocchio/.pixi/envs/default/lib/libpinocchio_default.so.3.4.0 (0x00007c5e9de00000)

Additional context

One possible cause is setting CMAKE_INSTALL_PREFIX=$CONDA_PREFIX in pixi.toml.

System

• OS: ubuntu 24.04
• Pinocchio version: devel (2f33ea1)

[abussy-aldebaran]

I'm willing to submit a PR if you tell me if and how you wish to fix this.

[jcarpent]

I do think @jorisv is the best to provide the proper guidance.
Thanks a lot, @abussy-aldebaran, for this issue and your willingness.

[abussy-aldebaran]

You're welcome.
Here are some ideas :

1. Set CMAKE_INSTALL_PREFIX to install, to mirror the build folder
2. I wonder if installing makes sense in a pixi setup ? If no, the install target could be disabled with CMAKE_SKIP_INSTALL_RULES (https://cmake.org/cmake/help/latest/variable/CMAKE_SKIP_INSTALL_RULES.html)

[jorisv]

Hello @abussy-aldebaran,

On OSX, GNU/Linux and Windows, we don't need to install pinocchio to use binary in the build directory:

• tests can be launched with ctest
• bindings can be run by setting the right PYTHONPATH

In my point of view it doesn't make so much sense to install pinocchio in a pixi/conda environment used to build pinocchio. I discourage it since some coworkers already fall in the same issue.

People still do it:

1. To avoid setting PYTHONPATH to use the python bindings
2. To use work in progress version of pinocchio to build another project

As you suggested, we can avoid setting CMAKE_INSTALL_PREFIX=$CONDA_PREFIX. But this will break the workflow of people doing installing because of (1).
(2) will maybe be solved by pixi build.

I can maybe provide a pixi tasks to run a python interpreter with PYTHONPATH set to build/bindings/python so people would have to do:

pixi run python path/to/my/script.py

But I'm not sure people will use it…

[abussy-aldebaran]

Thanks for the answer

In my point of view it doesn't make so much sense to install pinocchio in a pixi/conda environment used to build pinocchio. I discourage it since some coworkers already fall in the same issue.

I agree. I don't remember why I made a ninja install in the first place, probably by habit. My point is that it can be hard to debug. If as you say, it's discouraged to do this, maybe using CMAKE_SKIP_INSTALL_RULES is a good solution. People who don't know any better won't have the issue. People who still want to do this can explicitly reenable it. If they don't, they will have an error saying that the target install doesn't exist.

[jorisv]

So, after some more investigation, conda (via cxx-compiler) set this environment variable:

export LDFLAGS="-Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,--allow-shlib-undefined -Wl,-rpath,/tmp/a/.pixi/envs/default/lib -Wl,-rpath-link,/tmp/a/.pixi/envs/default/lib -L/tmp/a/.pixi/envs/default/lib"

In activation.sh, I unset the LDFLAGS value set by cxx-compiler. But I put back some flags because it allow to build with clang:

export LDFLAGS="-Wl,-rpath,$CONDA_PREFIX/lib -Wl,-rpath-link,$CONDA_PREFIX/lib -L$CONDA_PREFIX/lib"

If I remove this part, the RPATH look first in the build directory, then in the install directory and there is no more linking issues when installing.

I have to check why I should use this flags when using clang.

[jorisv]

I can't find a nice workaround on clang. If I don't set -Wl,-rpath,$CONDA_PREFIX/lib, executable can link against the system libstdc++ that is not compatible with conda.

I will remove this line from activation.sh and put it in activation_clang.sh to remove the issue for most users.

[nim65s]

RPATH takes precedence over LD_LIBRARY_PATH, so maybe leave RPATH to build dir and set LD_LIBRARY_PATH to conda prefix ?

[nim65s]

you could also try to exclude system things with -nodefaultlibs (https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-nodefaultlibs)

[jorisv]

I know conda-forge discourage the use of LD_LIBRARY_PATH (no activation scripts will setup this variable).
We can do that for clang as a workaround.

With GCC, they distribute a modified specs file that will add -rpath $CONDA_PREFIX/lib after all linker arguments.
Sadly, clang doesn't read this file but we can use clang config file to achieve the same thing. Since clang 20, we can append linker arguments.

I have tried and it's working. But maybe this should be managed by the clangxx package itself…