Bug#643891: [gcc-4.6] print-file-name acting non-standard and problematic

[Matthias Klose <doko@debian.org>]

On 09/30/2011 05:58 PM, Allan Sandfeld Jensen wrote:
> Package: gcc-4.6
> Version: 4.6.1-13
> Severity: normal
> 
> --- Please enter the report below this line. ---
> If you call gcc --print-file-name=liblto_plugin.so, Debian gcc 4.6.1 returns
> /usr/lib/gcc/x86_64-linux-gnu/4.6/liblto_plugin.so
> and the gcc --print-prog-name=liblto_plugin.so returns
> liblto_plugin.so

yes, the latter doesn't look ok.

> on non-Debian platforms both of these calls return consistently
> /usr/lib/gcc/x86_64-linux-gnu/4.6.1/liblto_plugin.so
> 
> Besides the obvious problem with --print-prog-name, the problem with the 
> returned value for --print-file-name is that
> 1) It is inconstant with other gcc file. For instance search for cc1 or lto-
> wrapper will return a path to /usr/lib/gcc/x86_64-linux-gnu/4.6.1/$name
> 2) The value is only correct for finding the file, nor for where gcc expects 
> to find it. So if you try make a new environment for gcc, the returned path 
> can not be used for where the file should be placed in the new environment. 
> liblto_plugin.so can be found at /usr/lib/gcc/x86_64-linux-gnu/4.6/ but 
> putting it there without a link from 4.6 to 4.6.1 will make gcc incapable of 
> finding it.

we do install into .../4.6/ to have a consistent path for installations across
subminor versions.  This path should also be reported when trying to get the
location for e.g. installing a plugin.

> I suspect the problem lies in the patch gcc-print-file-name.diff which claims 
> to remove the minor version number, for some reason that only work with the 
> plugin library and not all files, but I do consider this incorrect behaviour, 
> and see no reason why it is trying to rewrite the gcc print-file-name output. 
> As a minimum it is inconsistant and inconvinient to tools trying to setup gcc 
> run-time environement. 
> 
> In particular this is a problem for the icecream(icecc) distributed 
> compilation tool.

ok, I'll try setting the base version instead directly, so that 4.6 is always
reported, but still having the subminor version reported in the --version output.