Bug 28737 - Intel oneAPI DPC++ compiler can not find standard headers and libs because of non-standard gcc paths
Summary: Intel oneAPI DPC++ compiler can not find standard headers and libs because of...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal enhancement
Target Milestone: ---
Assignee: Thomas Backlund
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-06 20:48 CEST by Oleg Bosis
Modified: 2021-04-25 00:48 CEST (History)
1 user (show)

See Also:
Source RPM: gcc-10.2.1-0.20210130.1.mga8.src.rpm
CVE:
Status comment:


Attachments

Description Oleg Bosis 2021-04-06 20:48:55 CEST
Description of problem:

I'm trying to use (mostly learn how to use) Intel's oneAPI compiler and tools and found it can not compile any example with errors stating missing standard C++ header files, libstdc++ and crtbegin.o.

After some time of searching the reason for the problem I've found that all officially supported (by Intel oneAPI) distributions use the same naming scheme for such files that differs from the one used in Mageia.

In particular the difference in the name of platform/architecture specific folders name: all supported distros use "triplet" name "x86_64-linux-gnu" or "x86_64-redhat-linux" or "x86_64-suse-linux" and Mageia uses "quadruple" name "x86_64-mageia-linux-gnu". The ones with distro name are seem to be correctly detected by DPC++ on corresponding distros only and the one without distro name looks to be universal. At least I've managed to make DPC++ compiler to work by making following symlinks:

pushd /usr/include/c++/10/
ln -s x86_64-mageia-linux-gnu x86_64-linux-gnu
popd

pushd /usr/lib/gcc/
ln -s x86_64-mageia-linux-gnu x86_64-linux-gnu
popd

Please add this compatibility links to gcc package.

Version-Release number of selected component (if applicable):
gcc-10.2.1-0.20210130.1.mga8

How reproducible:
always

Steps to Reproduce:
1. 
2.
3.
Comment 1 Aurelien Oudelet 2021-04-06 20:59:28 CEST
Hi, thanks for reporting this.
This seems a good request to provide compatibility.


Assigned to the package maintainer.

Assignee: bugsquad => tmb
CC: (none) => ouaurelien

Comment 2 Thomas Backlund 2021-04-25 00:48:20 CEST
Sorry, 

but I wont change behaviour or packaging of gcc in a stable release as even those "simple symlinks" can cause possible behavior change in detecting and building stuff...

There is some wery fragile compiler detection stuff out there so I dont want to cause any issues...

However this is being changed in upcoming gcc 11 wich is now in testing for Cauldron / upcoming Mga9 where we switch to triple: <arch>-mageia-linux

besides for armv7 where we keep the <arch>-mageia-linux-gnueabi wich is recommended for ensuring detecting that we are using the new abi

Status: NEW => RESOLVED
Version: 8 => Cauldron
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.