* Nicholas Miell:
On 7/25/21 4:28 AM, Florian Weimer wrote:
> * Sandro Mani:
>
>> I'd need help with the following issue with apitrace, which failed the
>> mass rebuild with:
>>
>> apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:70:
>> undefined reference to `__libc_dlopen_mode'
>> apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:72:
>> undefined reference to `__libc_dlsym'
>>
>> The code triggering this is below. Have these symbols disappeared from
>> libc resp is there any alternative?
>
> These internal GLIBC_PRIVATE symbols are gone and won't come back.
>
> Not sure why this code isn't using RTLD_NEXT.
>
Because they're interposing dlsym itself and attempting to call
dlsym(RTLD_NEXT, ...) resolves to the interposed dlsym function and
dies due to infinite recursion.
Oops, I see.
> We are working on improving LD_AUDIT support, which is the plugin
API of
> the dynamic loader. It can in theory be used to implement such things.
> But API tracing is probably best implemented within the traced libraries
> themselves, rather than on the side.
>
This isn't viable when you have multiple libraries from different
vendors, some or all of which are beyond your control.
Which part? The tracing-in-libraries aspect?
LD_AUDIT shouldn't have this problem.
Dyninst and Systemtap might alos be worth investigation.
Thanks,
Florian