[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #4 from npl at chello dot at --- Is it really an excuse that it behaved like that forever? Given that -march and -sysroot (and spec files AFAIR) already affect the search paths, its not reasonable to expect -L wont work. I know that the linker is separate, but just adding the searchpath should be easy? If there is a new flag, please show in the returncode whether the library was found or not. If you want to inquire the linker, then maybe some "link-only" mode would be better, just invoking the linker with the usual flags and passing though additional commands.
[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 --- Comment #3 from John Ericson --- Hmm, the GHC issue I meant to link I think is https://gitlab.haskell.org/ghc/ghc/issues/11042 . From the looks of it, I might have pasted the wrong URL anyways, but in any event GHC switched from Trac to (its own) GitLab, so the link would have eventually rotted regardless.
[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 --- Comment #2 from John Ericson --- Indeed it has. Are you worried about the breakage then? Could we make a new --print-library-name= ? The old name is pretty bad anyways, so I'd like a flag with that name to exist regardless. I am still unclear on the degree to which -L is really a GCC concern vs just something forwarded to the linker. If the latter, maybe I should also open a binutils issue so as not to induce a layer violation? The GCC --print-library-name= would use the linker --print-library-name= so as to not track something (-L path) it otherwise doesn't need to track. -- Also, if all this sounds like a rather theoretical layer violation, https://ghc.haskell.org/trac/ghc/timeline?from=2018-10-26T02%3A26%3A15Z&precision=second is an example of a practical ramification of this. The gist of this scenario is we have another compiler, GHC, that uses gcc. Wrapping gcc to add -L is a leaky abstraction because GHC uses --print-file-name to get at the library location. It itself will turn its own -L into -B to get around this issue, but any interpositioned -L will do nothing. Of course the warpper script could also use -B, but that sure feels like a sledgehammer to solve this problem.
[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-26 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed - but it behaved this way since forever.
