documentation of papi_library_init and compatibility

I’m trying to understand the compatibility designed in (if there is any expected at all) of papi versions.

The papi init call has a return code that seems to indicate that if I don’t have an exact match of the papi shared library/headers with which the application was compiled then I should not expect anything to work (or at least to not work reliably). Is this very strictly the case?

I’m particularly interested in the following set of calls:

    rc = PAPI_library_init(PAPI_VER_CURRENT);
(ignore version incompatibility rc values from _init; assume papi_name is a user input string )
    rc = PAPI_event_name_to_code((char*)papi_name, &papi_code);
    ...
    rc = PAPI_get_event_info(papi_code, &papi_info);
    ...
    comp_info = PAPI_get_component_info(papi_info.component_index);

Where ultimately I want to get the system’s current correct perfmon name for the papi event name from comp_info.

If I build with say, 5.7 and a 5.3 derived libpapi is found at runtime, is the event data management such that I should get correct answers?

If I build with 5.7 and a 6.0.0 derived libpapi is found at runtime, would i (again) get correct answers?

Or in either or both cases should I strongly expect that somehow memory will get abused instead?

Assume that if the ‘wrong’ libpapi is found, the matching wrong libpfm.so is also going to be found.

I realize from a software engineering point of view this is an awful question – what is expected/likely vs what is officially supported behavior. I assume from the man page of init that only exact library match is officially supported.

I consider the lack of back/forward compatibility detail in the documentation a minor documentation bug. It would be nice if this were covered in the faq or the …_init call.

Comments (2)