https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758
--- Comment #2 from John Ericson <John.Ericson at Obsidian dot Systems> --- 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.
