Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Colcon extends LD_LIBARAY_PATH with cross compiled libraries #625

Open
cwecht opened this issue Mar 11, 2024 · 4 comments
Open

Colcon extends LD_LIBARAY_PATH with cross compiled libraries #625

cwecht opened this issue Mar 11, 2024 · 4 comments

Comments

@cwecht
Copy link

cwecht commented Mar 11, 2024

I am trying to cross compile rosbag2 for QNX 7.2 on Ubuntu Jammy. If I do so, cmake crashes for packages which depend on zstd_vendor with this error

/usr/bin/cmake: error while loading shared libraries: libc.so.5: cannot open shared object file: No such file or directory

The reason for that is that:

  • QNX 7.2 ships with libc.so.5
  • Ubuntu Jammy ships with libc.so.6
  • QNX and Linux both use ELF as their file format for executable files
  • zstd_vendor build libzstd.so
  • CMake links agains libzstd.so
  • Colcon adds libraries build in dependencies to LD_LIBARARY_PATH
  • This results for packages which depend on zstd_vendor to in cmake trying to load libzstd.so from zstd_vendor. This will fail because this version of libzstd.so is build against libc.so.5 - which is not available on Ubuntu Jamme and therefore results in a failure.

I was able to circumvent this issue by reconfiguring zstd_vendor so that is creates static libraries in stead of shared libraries. However, this issue concernes me a bit. It should be possible to cross compile projects using Colcon without the potential risk of injecting newly build libraries into the build system.

At this point I'm not entirely sure how to fix this issue. My first idea was to have some kind of "cross compilation flag" which turns this "LD_LIBRARY_PATH" behavior off entirely during build time. However, as think more about it: in general it should not be possible that parts of the build system end up using just build libraries by accident - this seems just wrong to me.

@cottsay
Copy link
Member

cottsay commented Mar 11, 2024

These hooks certainly aren't designed for cross-compiled builds like this, so I'm not surprised that strange behaviors like this manifest.

The easiest and most supported way to block the LD_LIBRARY_PATH modifications would be to use the environment variable COLCON_EXTENSION_BLOCKLIST=colcon_core.environment.library_path during the build. You may also want to consider COLCON_EXTENSION_BLOCKLIST=colcon_core.environment.path to block automatic changes to PATH as well.

Docs for that variable are here: https://colcon.readthedocs.io/en/released/reference/global-arguments.html?highlight=COLCON_EXTENSION_BLOCKLIST#environment-variables

@cwecht
Copy link
Author

cwecht commented Mar 22, 2024

Thank you for your anwser! Using COLCON_EXTENSION_BLOCKLIST actually helps making the build work. But it also supresses the generation of the LD_LIBRARY_PATH hooks alltogether, which means that during runtime on the target no libraries can be found.

I suppose we would need something like that but which only blocks the usage of the hooks of a certain extensions during build time. The hooks itself are still valuable and required on the target machine but can cause harm during build.

@cwecht
Copy link
Author

cwecht commented Mar 22, 2024

We were now able to circumvent this issue

printf "#!/bin/bash\nLD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu /usr/bin/cmake "$@"" > /tmp/cmake_wrapper
chmod +x /tmp/cmake_wrapper
export CMAKE_COMMAND="/tmp/cmake_wrapper"

With this workaround it is possible to protect cmake from the modified LD_LIBRARY_PATH. But this feels like a workaround to me. At this point I wonder whether it is possible with reasonable effort to protect parts of the toolchain (cmake, ctest, etc) from the modified LD_LIBRARY_PATH?

@bluecorvetteai
Copy link

Just ran into this as well. Thank you for the insight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants