https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #14 from Jakub Jelinek ---
(In reply to Sam James from comment #1)
> As pointed out in the CMake bug, Fedora is doing
> https://src.fedoraproject.org/rpms/gcc/c/
> 46a6d807645871b4d243ef2be35f9677bd4d68cb?branch=rawhide but I don't k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #13 from Sam James ---
I'll investigate over the weekend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #12 from Jason Merrill ---
So if toolexeclibdir is /usr/lib64, how is modules.json ending up in
/usr/lib/gcc/x86_64-pc-linux-gnu/15/? It's supposed to be in toolexeclibdir.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #11 from Sam James ---
(In reply to Sam James from comment #10)
> OK, avoiding speculation and getting back to facts:
> ```
> $ cat ./build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++23/relpath.log
> called with '/usr/lib64' and
> '/usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #10 from Sam James ---
OK, avoiding speculation and getting back to facts:
```
$ cat ./build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++23/relpath.log
called with '/usr/lib64' and
'/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #9 from Sam James ---
(In reply to Jason Merrill from comment #7)
> (In reply to Sam James from comment #0)
> > $ A=/usr/lib/gcc/x86_64-pc-linux-gnu/15/
> > $
> > B=/usr/lib/gcc/x86_64-pc-linux-gnu/lib/gcc/x86_64-pc-linux-gnu/15/inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #8 from Sam James ---
I may well be getting mixed up then, sorry.
Are the paths meant to be relative to the .json file? The file for me is at
/usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.modules.json, and std.cc is at
/usr/lib/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #7 from Jason Merrill ---
(In reply to Sam James from comment #0)
> $ A=/usr/lib/gcc/x86_64-pc-linux-gnu/15/
> $
> B=/usr/lib/gcc/x86_64-pc-linux-gnu/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc
> $ contrib/relpath.sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #6 from Jonathan Wakely ---
Yes for the overwhelming majority of users, it would make sense for
contrib/relpath.sh (or libstdc++-v3/src/c++23/Makefile.am) to use GNU realpath
when available.
https://www.gnu.org/software/coreutils/ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #5 from Sam James ---
Unfortunately, realpath isn't in POSIX shell, but:
```
$ realpath --relative-to=$A
/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc
include/g++-v15/bits/std.cc
```
and indeed using `"source-path"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #4 from Jonathan Wakely ---
Ah no, because we're just using it from the makefile, not in C++ code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #3 from Jonathan Wakely ---
I wonder if using std::filesystem (or std::experimental::filesystem for C++14)
would make this path handling more robust.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #2 from Sam James ---
(To state the obvious: the PR119081 fix didn't solve it for this case.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #1 from Sam James ---
As pointed out in the CMake bug, Fedora is doing
https://src.fedoraproject.org/rpms/gcc/c/46a6d807645871b4d243ef2be35f9677bd4d68cb?branch=rawhide
but I don't know if there's a PR for that (couldn't find one).
14 matches
Mail list logo
