Failure to link with LTO: undefined reference to `libsinsp::cri::cri_interface<libsinsp::cri::cri_api_v1alpha2>::get_cri_runtime_type()

[hhoffstaette]

Describe the bug

I recently updated sysdig in Gentoo to 0.38.x (with libs-0.17.2) and wanted to see how it fares with LTO. I know that there are several merged/open/in-progress issues slated for 0.18 but I didn't see this one yet, so here it is.

In summary it's a failure to link the final sysdig/csysdig executables:

/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/portage/dev-debug/sysdig-0.38.1/temp/ccQH9U47.ltrans25.ltrans.o: in function `libsinsp::container_engine::cri_async_source::container_type(libsinsp::cgroup_limits::cgroup_limits_key const&) const':
<artificial>:(.text+0x220): undefined reference to `libsinsp::cri::cri_interface<libsinsp::cri::cri_api_v1>::get_cri_runtime_type() const'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: <artificial>:(.text+0x235): undefined reference to `libsinsp::cri::cri_interface<libsinsp::cri::cri_api_v1alpha2>::get_cri_runtime_type() const'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/portage/dev-debug/sysdig-0.38.1/temp/ccQH9U47.ltrans26.ltrans.o: in function `libsinsp::container_engine::container_async_source<libsinsp::cgroup_limits::cgroup_limits_key>::lookup_sync(libsinsp::cgroup_limits::cgroup_limits_key const&, sinsp_container_info&)':
<artificial>:(.text+0x5385): undefined reference to `libsinsp::cri::cri_interface<libsinsp::cri::cri_api_v1>::get_cri_runtime_type() const'
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: <artificial>:(.text+0x54a1): undefined reference to `libsinsp::cri::cri_interface<libsinsp::cri::cri_api_v1alpha2>::get_cri_runtime_type() const'

How to reproduce it

Build sysdig-0.38.x+libs-0.17.2 with LTO (compile with '-O2 -flto', link with '-fuse-linker-plugin -flto=auto')

Expected behaviour

Successful link stage of the final executables.

Environment

Gentoo Linux, ~amd64 (testing)

• Kernel:

6.10.0 :)

• Installation method:

From source - I am the package maintainer

Additional context

This depends on optimization (likely inlining), as building with -O (instead of -O2) seems to produce executables that work. 🤷

[FedeDP]

Hi! Thanks for opening this issue! I think this might get fixed in 0.18.0: #1895

[hhoffstaette]

Hi! Thanks for opening this issue! I think this might get fixed in 0.18.0: #1895

Wonderful, thanks! I missed that PR because of the name, but I can confirm that the patch fixes building with -O2 using gcc+LTO. 🎉

[poiana]

@hhoffstaette: You must be a member of the falcosecurity/libs-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your maintainers of falcosecurity/libs and have them propose you as an additional delegate for this responsibility.

In response to this:

/milestone 0.18.0

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[hhoffstaette]

Apparently I cannot set the milestone, so please do and close. Thanks! 🫶

[FedeDP]

/milestone 0.18.0
/close

[poiana]

@FedeDP: Closing this issue.

In response to this:

/milestone 0.18.0
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[FedeDP]

/milestone 0.17.3