[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

ilg-ul wrote: I took some time to analyse the failed tests. I managed to reproduce them (except `rocm-detect.hip`) on my macOS, so I had more freedom to experiment. The failing tests are: - `Clang::Driver/mingw-sysroot.cpp` - `Clang::Driver/no-canonical-prefixes.c` -

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

mstorsjo wrote: > I'm convinced that such links were occasionally used before, just that the > result was not necessarily an error, I would say that in most cases using the > system libraries is functional, and this explains why such cases were not > reported till now. Not necessarily; this

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

ilg-ul wrote: > You make it sound like nobody else might ever have used such symlinks before > - isn't that quite a big assumption? Ah, sorry for the confusion, I did not intend to make it sound like a big assumption. I'm convinced that such links were occasionally used before, just that

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

mstorsjo wrote: > > it makes me wonder if someone actually is relying on the current behaviour > > To rephrase your question, you ask if someone is using a configuration with a > folder where various custom libraries are and bin folder with a link to the > actual clang, and expects for clang

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

ilg-ul wrote: > resolving this to the actual clang binary would indeed seem like the right > thing to do. Great! The new simplified patch does exactly this. > it makes me wonder if someone actually is relying on the current behaviour To rephrase your question, you ask if someone is using a

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

mstorsjo wrote: > > I haven't checked closely > > Hi Martin, please check the #66704 bug report, the current behaviour is > plainly wrong, I would kind of agree with that in general - resolving this to the actual clang binary would indeed seem like the right thing to do. But it makes me

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

https://github.com/ilg-ul updated https://github.com/llvm/llvm-project/pull/68091 >From f3812174546270051c4a2903b9a99408bf5b7ba0 Mon Sep 17 00:00:00 2001 From: Liviu Ionescu Date: Tue, 3 Oct 2023 14:07:48 +0300 Subject: [PATCH 1/3] [clang][driver] Use platform specific calls to get the

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

ilg-ul wrote: > I haven't checked closely Hi Martin, please check the #66704 bug report, the current behaviour is plainly wrong, clang does not pick the correct libraries and silently uses the system libraries, which leads to very subtle and hard to debug errors if the new version is several

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

mstorsjo wrote: FWIW, I'd be quite wary about modifying the logic here (whatever it is - I haven't checked closely); if we used to resolve to one point of a symlink before, and now resolve to the other end, I can almost guarantee you that there are dozens of existing users that rely on the

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

@@ -331,6 +340,56 @@ static void SetInstallDir(SmallVectorImpl , // path being a symlink. SmallString<128> InstalledPath(argv[0]); +#if defined(__linux__) ilg-ul wrote: > Can we use `getMainExecutable()` instead? Good point! > So is the problem here

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

https://github.com/bjope edited https://github.com/llvm/llvm-project/pull/68091 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

@@ -331,6 +340,56 @@ static void SetInstallDir(SmallVectorImpl , // path being a symlink. SmallString<128> InstalledPath(argv[0]); +#if defined(__linux__) bjope wrote: I was kind of thinking the same. And then started to wonder about why SetInstallDir

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

@@ -331,6 +340,56 @@ static void SetInstallDir(SmallVectorImpl , // path being a symlink. SmallString<128> InstalledPath(argv[0]); +#if defined(__linux__) AaronBallman wrote: Can we use

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

Endilll wrote: You have failed tests on Linux CI: ``` Failed Tests (4): Clang :: Driver/mingw-sysroot.cpp Clang :: Driver/no-canonical-prefixes.c Clang :: Driver/program-path-priority.c Clang :: Driver/rocm-detect.hip ``` Windows CI has another test in Clang interpreter failing, but that

[clang] [clang][driver] Use platform specific calls to get the executable absolute path (PR #68091)

https://github.com/ilg-ul edited https://github.com/llvm/llvm-project/pull/68091 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits