On Tue, Dec 9, 2025, at 16:04, Aaron Merey wrote: > On Tue, Dec 9, 2025 at 8:10 AM Mark Wielaard <[email protected]> wrote: > > On Mon, Dec 08, 2025 at 08:48:54PM -0500, Aaron Merey wrote: > > > Currently we check for openat2 RESOLVE_IN_ROOT support using > > > AC_LINK_IFELSE. HAVE_OPENAT2_RESOLVE_IN_ROOT is defined when > > > AC_LINK_IFELSE succeeds. > > > > > > It is possible for openat2 and RESOLVE_IN_ROOT to be > > > present in headers but the kernel does not implement it. In this case > > > AC_LINK_IFELSE succeeds and HAVE_OPENAT2_RESOLVE_IN_ROOT is defined, > > > but openat2 calls using RESOLVE_IN_ROOT always fail with ENOSYS for > > > instance. > > > > > > Fix this by using AC_RUN_IFELSE instead of AC_LINK_IFELSE when > > > determining whether to define HAVE_OPENAT2_RESOLVE_IN_ROOT. > > > > I agree with Arnout in the other thread that this is probably not > > needed here. There is already fallback code in both link_map and > > dwfl_segment_report_module there is a check for enosys to then use > > reguar open. Is that not working as intended? > > (I discussed this with Mark off-list but I'll repeat here): I prefer > to avoid building with HAVE_OPENAT2_RESOLVE_IN_ROOT if we know at > build time that it's not supported.
Thanks for looping back here. My concern with that approach is that you don't 'know' at build time whether it's supported on the target machine... > OTOH I'm not opposed to just sticking with the existing runtime checks. So I'd prefer those ;) Kind regards, -- Arnout Engelen Engelen Open Source https://engelen.eu
