ARM-software/ComputeLibrary conflicts with kleidiai

[BillyONeal]

After microsoft/vcpkg-tool#1768 vcpkg now correctly diagnoses when packages conflict with each other, which has exposed a conflict between OpenVINO on ARM and KleidiAI.

See https://github.com/microsoft/vcpkg/tree/master/ports/kleidiai and https://github.com/microsoft/vcpkg/blob/4acadb7d732e662bbf130c4849be6d3a0aa6f6b9/ports/openvino/portfile.cmake#L77-L91

[morgolock]

Hi @BillyONeal

ACL has a copy of KleidiAI in its third_party/kleidiai folder, but this is only used internally during the build. Those sources get compiled into ACL’s objects and libraries, but they are not exposed in the install step. If you look at the install rules in the SCons scripts, they only cover ACL’s own headers (arm_compute, support, utils, etc.), libraries, and binaries. No KAI headers or CMake files are ever installed into the prefix.

Because of this, ACL itself cannot create a conflict in vcpkg, it never installs include/kai/* or anything similar. If a layout collision is being reported by vcpkg, that must be caused by another port (for example, OpenVINO’s port) installing KleidiAI into the global prefix. From ACL’s side there’s nothing to change.

I'll discuss this with the OpenVINO team. I think it would be best for you to raise an issue in the OV project.

Hope this helps

[alvoron]

@BillyONeal I have prepared a possible solution: openvinotoolkit/openvino#32603
Is it possible to test it before I merge it to OpenVINO master?

[BillyONeal]

@BillyONeal I have prepared a possible solution: openvinotoolkit/openvino#32603 Is it possible to test it before I merge it to OpenVINO master?

I do not think this truly fixes the problem as it still leaves potential link-time conflicts. OpenVINO needs to use the copy of KleidiAI that the kleidiai port says, not vendor some different version.

But it may be better than the current situation where we effectively have to disable all ARM customers

[alvoron]

@BillyONeal could you please explain your concerns about the proposed solution?
KleidiAI is a submodule of OpenVINO project and we'd like to control its build process.
I think the proposed solution should work fine, because OpenVINO statically links kleidiai lib using hardcoded paths.
So, I assume, there is no chance to have link-time conflicts.

[BillyONeal]

I think the proposed solution should work fine, because OpenVINO statically links kleidiai lib using hardcoded paths.
So, I assume, there is no chance to have link-time conflicts.

The problem is not in building OpenVINO. The problem is the downstream customer who ends up with kleidiai.lib and openvino.lib on their link line.

• (I didn't check the real names, I hope this conveys the point though)

[alvoron]

@BillyONeal
KleidiAI is used by OpenVINO CPU plugin. It's a loadable plugin, not a regular shared library.
KleidiAI is statically linked PRIVATE into the plugin, so KleidiAI symbols are embedded and hidden inside the plugin.
If we apply the proposed fix, OpenVINO won't install kleidiai libraries.

If downstream customers have kleidiai.lib on their link line, I don't expect to see any link-time conflicts because:

• the plugin's KleidiAI symbols are not exported
• there's no kleidiai.lib installed by OpenVINO for anyone to link against
• the CPU plugin is loaded as a runtime module, not linked directly

[BillyONeal]

KleidiAI symbols are embedded and hidden inside the plugin.

I believe that is possible on Windows (not exporting the symbols from the DLL) but less so on the non-Windows platforms that dump every .so into the same symbol namespace.

[alvoron]

@BillyONeal right, Linux symbol visibility is a consideration, however OpenVINO sets -fvisibility=hidden via set(CMAKE_CXX_VISIBILITY_PRESET hidden) in cmake file. So, I assume, even on non-Windows platforms OpenVINO hides all symbols.