xiar missing in intel-oneapi-compiler-shared-2025.0

[rudi-gaelzer]

The xiar tool (archive tool for IPO objects) was not distributed with the 

intel-oneapi-compiler-shared-2025.0 rpm pack for Fedora linux.

It was present until  intel-oneapi-compiler-shared-2024.2 and stored in 

/opt/intel/oneapi/compiler/2024.2/bin

Was this intentional?

[Ron_Green]

I am attempting to find our which rpm package has xiar.

But I am curious - you are extracting the RPMs from the installer and using the RPMs directly?  From what product download or repo package are you pulling?  

[rudi-gaelzer]

Hi Ron.

I'm running Fedora Linux, so I'm using dnf to install/upgrade OneAPI.

The xiar app was provided by: 

intel-oneapi-compiler-shared-2024.2-2024.2.1-1079.x86_64 : Intel(R) Compiler Shared Files
Repo         : @system
Matched From :  
Filename     : /opt/intel/oneapi/compiler/2024.2/bin/xiar

I installed all OneAPI files with RPMs provided by the Yum/dnf repository, which I installed as per instructions in: 

https://www.intel.com/content/www/us/en/docs/oneapi/installation-guide-linux/2025-0/yum-dnf-005.html#FORTRAN-YUM-DNF

$>cat /etc/yum.repos.d/oneAPI.repo  
[oneAPI]
name=Intel(R) oneAPI repository
baseurl=https://yum.repos.intel.com/oneapi
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://yum.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB

I can use the GNU ar, no problem.  It's just that I was used to archive objects compiled with ifort/ifx using xiar.

[Ron_Green · Accepted solution]

I should have remembered - xiar was used for the old Classic Compiler IPO generated objects and libraries.  

for the new LLVM lto ( IPO ) binaries we have a ar tool in .../bin/compiler/llvm-ar

This recognizes our objects with Intel GPU offload kernel code along with the CPU code (fat objects)

[rudi-gaelzer]

OK, found it.

The syntax is similar to the old xiar, I guess?

[Ron_Green]

yes, very similar.  
But if you have older libraries and/or objects built with ifort -ipo then that older IPO format will not be recognized by llvm-ar and you will need an older copy of xiar to manipulate those older binaries. 

[rudi-gaelzer]

Sorry to resume a discussion that was already considered solved, but  I only had time to come back to this issue now.

As I mentioned above, I have llvm-ar installed in 

/opt/intel/oneapi/compiler/2025.0/bin/compiler

but the path to this directory is not set.

Could you help me out here?

Since always I have set the paths to intel compilers by inserting the line 

source /opt/intel/oneapi/setvars.sh

in .bash_profile.

However, that is only setting the following paths in the system:

/opt/intel/oneapi/vtune/2025.0/bin64

/opt/intel/oneapi/mpi/2021.14/bin

/opt/intel/oneapi/mkl/2025.0/bin

/opt/intel/oneapi/dpcpp-ct/2025.0/bin

/opt/intel/oneapi/dev-utilities/2025.0/bin

/opt/intel/oneapi/debugger/2025.0/opt/debugger/bin

/opt/intel/oneapi/compiler/2025.0/bin

/opt/intel/oneapi/advisor/2025.0/bin64

The latest package that provides llvm-ar that I have installed in my system is:

intel-oneapi-openmp-2025.0-2025.0.4-1519.x86_64.rpm

Am I doing something wrong?

[Ron_Green]

The path is NOT added for a reason:  customers with a default Clang/LLVM installation want to use the LLVM tools from Clang, and not from Intel.  At least, that was their complaint when we added the bin/compiler path by default some years back.  So a user who wants to use the Intel supplied LLVM tools have to manually add this path.

[rudi-gaelzer]

Thank you.  I will set the path manually.

[Ron_Green]

a follow-on discussion was the suggestion to rename the Intel LLVM tools so there is no name clash with the Clang/LLVM tools - interesting idea, however it would require all users to change their Make and Cmake builds for every application.  This is a non-starter for customers.