oneAPI 2023 linking problems.

[Daniel_H]

Hi,

I'm trying the new oneAPI 2023 (2023.0.0.20221201) and get into some trouble.

Since the ICPC complains that it will be abandoned sooner than later (fair enough), I switched to ICPX.

And now in my autotools project when compiling I got the following errors:

bfd plugin: LLVM gold plugin has failed to create LTO module: Not an int attribute (Producer: 'Intel.oneAPI.DPCPP.Compiler_2023.0.0' Reader: 'LLVM 14.0.6')

It occurs when libtool is applying 'ar cr' or 'ranlib' to create a static library out of a bunch of objects files.

Later at final linking there are a lot of missing symbols.

It is not happening with previous version of oneAPI (2022.1.0.20220316).

Any clue on where I have to start digging to solve this issue? My Google attempts pointed me to an ld/ld.lld issue but I could not find any way to get something working.

Thanks,

PS: sorry for duplicate post...

[Daniel_H]

More info and a workaround...

The error message tells me that Reader: 'LLVM 14.0.6'.

So I tested the compilers versions using $CXX -x c /dev/null -dM -E | grep clang.

And oneAPI 2023 claims this: #define __clang_version__ "16.0.0 (icx 2023.0.0.20221201)".
While oneAPI 2022 gives: #define __clang_version__ "14.0.0 (icx 2022.1.0.20220316)".

This later could explain why 2022 version does not complain: they have the same major version.

Eventually I realized that the "regular" llvm-clang is installed on my system and it tells: #define __clang_version__ "14.0.6 " which is exactly the version from the error.

So it appeared I must be using somewhere the regular clang++ instead of icpx. I usually define CC=... and CXX=... before calling configure and all run fine.

It took me a while and lot of head scratching before I realized that I wrongly assumed that the peruse of setvars.sh and icx/icpx should use its own set of paths and tools which supersede the default ones.

Eventually I had to explicitly define AR, RANLIB and LD to be: llvm-ar, llvm-ranlib and lld-link with full path (e.g. ${CMPLR_ROOT}/linux/bin-llvm/) to be able to compile.
Strictly speaking defining LD seems not mandatory, but since I'm there anyway...

All this is unfortunate, because I would have expected that the end user should be kept away of these gory path details.
Is there any better way to solve this situation?
My 5 cents idea would be to define some "ic-ar", "ic-ranlib",... in the oneAPI path?
This would mimic cross-compiler, make things self-consistent and independent of the other compilers natively installed, and also avoid bothering about path.

Thanks.

[SeshaP_Intel]

Hi,

Thank you for posting in Intel Communities.

Could you please provide a reproducer and steps to reproduce so that we can investigate this issue more from our end?

Thanks and Regards,

Pendyala Sesha Srinivas

[SeshaP_Intel]

Hi,

We haven't heard back from you. Could you please provide an update on your issue?

Thanks and Regards,

Pendyala Sesha Srinivas

[Daniel_H]

Hi,

Sorry for the late reply, some time far from screens. Thanks for you interest.

Unfortunately it is part of a large project and reducing it to a minimalistic one would take me a lot of time.

For the time being I'll stick to the peruse of explicit declaration of AR and RANLIB, which despite its heaviness works fine.

If I have time to create a small "reproducer", I'll re-post.

Regards,

Daniel

[SeshaP_Intel]

Hi,

Could you please provide an update on your issue? Could you please share the sample reproducer with us?

Thanks and Regards,

Pendyala Sesha Srinivas

[Daniel_H · Accepted solution]

Hi,

I really appreciate your professional concern in trying to help me solving this issue.
Unfortunately I didn't succeed in reducing the problem to its simplest expression.

While doing this I some sort of convinced me that I'm facing the normal behaviour of AUTOMAKE/LIBTOOL (which could sometimes be quite obscure).
And here are my conclusions:

1) Libtool tries to find AR and RANBLIB by itself, and fall on the gcc default ones, which are the ones installed by my linux distro.
And hence all the oneAPI ones are skipped.
2) Since my default RANLIB version is "incompatible" with the current oneAPI one, they obviously refuse to collaborate.
3) Forcing, by hand, AR and RANLIB to point to oneAPI's ones make all work correctly (compiling ad running). So oneAPI is self consistent.

As a matter of solutions:

1) I was explicitly setting AR=${CMPLR_ROOT}/linux/bin-llvm/llvm-ar and RANLIB=${CMPLR_ROOT}/linux/bin-llvm/llvm-ranlib before running configure. Fine but boring.
2) Now I'm forcing automatic assignment of these values within my configure.ac when detecting CXX containing "icpx".

Now considering:
- that my project is large,
- that I've unfortunately not much time to investigate further in a reduced "reproducer",
- that for the moment the project is "not publishable" as is,
- that all this could evolve as time goes on, with further updates of my distro.

I'll "close" the issue.

I guess that my solution 2) is doing the job correctly.

Sorry for the nuisance, but when posting I was hoping that the error message would have ringed a bell to some people and led me on a path of solution, saving me from having to dig in all directions.

Daniel

[SeshaP_Intel]

Hi,

Glad to know that your issue is resolved. Thanks for sharing the solution with us. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.

Thanks and Regards,

Pendyala Sesha Srinivas