Skip to content

[SYCL] Rename clang binaries to dpclang#21598

Open
dm-vodopyanov wants to merge 1 commit intointel:syclfrom
dm-vodopyanov:rename_clang_to_dpclang
Open

[SYCL] Rename clang binaries to dpclang#21598
dm-vodopyanov wants to merge 1 commit intointel:syclfrom
dm-vodopyanov:rename_clang_to_dpclang

Conversation

@dm-vodopyanov
Copy link
Contributor

This patch renames clang, clang++, clang-c++, clang-cc, clang-cpp, clang-g++, clang-gcc, clang-cl to the same names with a prefix dp to make sure the SYCL compiler package can be co-existed with the official clang package for various Linux distributions.

This patch renames `clang`, `clang++`, `clang-c++`, `clang-cc`, `clang-cpp`,
`clang-g++`, `clang-gcc`, `clang-cl` to the same names with a prefix `dp` to make
sure the SYCL compiler package can be co-existed with the official clang
package for various Linux distributions.
@dm-vodopyanov dm-vodopyanov requested review from a team as code owners March 23, 2026 17:09

SmallString<128> ClangPath(C.getDriver().Dir);
llvm::sys::path::append(ClangPath, "clang");
llvm::sys::path::append(ClangPath, "dpclang");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably need to change sycl/doc as well

@tahonermann
Copy link
Contributor

Thanks, @dm-vodopyanov. This is more change than I was expecting. How did you identify all the places to change? Trial and error by running the testsuite? Or a more systematic approach?

Copy link
Contributor

@dvrogozh dvrogozh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's just a partial solution as it takes care to rename only clang* kind of things and leaves behind a bunch of lvm-* binaries, include/clang/, libLLVM*, etc. I would like to propose alternative solution which I hope will be easier:

  1. Change the install prefix for all the stuff borrowed from LLVM. Let default be $libdir/dpclang-MAJOR/ as that's prescribed default by File System Hierarchy Standard. This will immediately resolve all the potential conflicts with already installed LLVM.
  2. Install additional targets, symlinks with the original names likes dpclang-MAJOR

Above will create the following installation target (assuming the default for LLVM installation):

$bindir/dpclang ->$prefix/bin/dpclang-MAJOR
$bindir/dpclang-MAJOR 
....
$libdir/libsycl.so.VERSION
$libdir/dpcpp-MAJOR/bin/clang
$libdir/dpcpp-MAJOR/bin/clang++
$libdir/dpcpp-MAJOR/bin/llvm-ar
...

@sarnex
Copy link
Contributor

sarnex commented Mar 24, 2026

I don't think this PR intended to solve the complete problem, I think it's just one piece of a larger set of changes.

If we try to implement all of those in one PR it will become huge, impossible to review, and more likely to have bugs.

@tahonermann
Copy link
Contributor

I would like to propose alternative solution which I hope will be easier

I tend to agree with @dvrogozh's alternate suggestion. What he proposes is similar to what is done for the oneAPI icx compiler distribution (that distribution puts the LLVM utilities in a compiler directory under $bindir).

@dvrogozh, could you please quote the section of the File System Hierarchy Standard that you feel justifies placing the LLVM assets under $libdir?

@dvrogozh
Copy link
Contributor

@dvrogozh, could you please quote the section of the File System Hierarchy Standard that you feel justifies placing the LLVM assets under $libdir?

It's section 4.6.1, https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html:

"/usr/lib includes object files and libraries. On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts.

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory."

Note that Debian's and Ubuntu's /usr/lib/x86_64-linux-gnu/ location is their own extension of the FHS /usr/lib defined in FHS, see https://wiki.ubuntu.com/MultiarchSpec.

Also, to place internal stuff to $libdir/<component>/ folder was the direction we've got from Debian/Fedora maintainers once we were packaging other projects (drivers) in these distributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants