Hi Alastair, When embedded in libmpi.so, these yaksa symbols are not intended to be public. It is an oversight if they are visible, so we will address it. I’ve created an issue on our Github to track https://urldefense.us/v3/__https://github.com/pmodels/mpich/issues/7306__;!!... . Cheers, Ken From: Alastair McKinstry via discuss <[email protected]> Date: Wednesday, February 19, 2025 at 4:35 AM To: [email protected] <[email protected]> Cc: Alastair McKinstry <[email protected]> Subject: [mpich-discuss] Yaksa public symbols Hi, I’m maintaining MPICH in Debian, and enabling HIP and other dependencies. In Debian we supply an ELF symbols file, tracking to make sure there are no unexpected ABI changes. With 4. 3. 0 there are changes and a lot of new yaksa-related symbols, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi, I’m maintaining MPICH in Debian, and enabling HIP and other dependencies. In Debian we supply an ELF symbols file, tracking to make sure there are no unexpected ABI changes. With 4.3.0 there are changes and a lot of new yaksa-related symbols, eg _Z33yaksuri_hipi_kernel_pack_LOR_boolPKvPvmPK17yaksuri_hipi_md_s@Base 4.3 _Z34yaksuri_hipi_kernel_pack_LAND_boolPKvPvmPK17yaksuri_hipi_md_s@Base 4.3 … hipFree@Base 4.3 yaksuri_hipi_pack_blkhindx_blkhindx_bool@Base 4.3 yaksuri_hipi_pack_blkhindx_blkhindx_char@Base 4.3 … Approx 8000 new symbols added to the public interface ! Is this expected ? are these part of the public interface or unexpected leakage? Can they be made private safely? Thanks Alastair McKinstry