[PATCH][RFC] Extend locations where to seach for Fortran pre-include.

[Martin Liška]

On 11/20/18 7:11 PM, Joseph Myers wrote:
> On Tue, 20 Nov 2018, Jakub Jelinek wrote:
> 
>> hardcoding /usr/include looks just very wrong here.  That should always be
>> dependent on the configured prefix or better be relative from the driver,
>> gcc should be relocatable.  Or at least come from configure.  It should e.g.
>> honor the sysroot stuff etc.
>>
>> That said, I think you need somebody familiar with the driver, perhaps
>> Joseph?

Hi Joseph.

> 
> I'd sort of expect structures like those in cppdefault.[ch] to describe 
> the relevant Fortran directories and their properties (such as being 
> sysrooted or not - and if sysrooted, I suppose you'll want to make sure 
> SYSROOT_HEADERS_SUFFIX_SPEC is properly applied).

We probably forgot to mention that the search mechanism happens in GCC driver.
It's because we want to include the file (via a Fortran -fpre-include) conditionally
only when found.

> 
> If this preinclude doesn't pass through the C preprocessor, directories in 
> which it is searched for will need multilib or multiarch suffixes.  

No, it's not C preprocessor.

> (Multilib suffixes on include directories for C are more or less an 
> implementation detail of how fixed headers are arranged in the case where 
> sysroot headers suffixes are used; they aren't really expected to be a 
> stable interface such that third-party software might install anything 
> using them, but I'm not sure if this preinclude is meant to come from 
> external software or be installed by GCC. 

It will come from glibc-devel package, and it's expected to be installed in:
usr/include/finclude/ for 64-bit header
and /usr/include/finclude/32/ for the 32-bit header.

 Multiarch suffixes, for systems 
> using Debian/Ubuntu-style multiarch directory arrangements, *are* intended 
> as a stable interface.  And multilib *OS* suffixes 
> (-print-multi-os-directory) are a stable interface, but only really 
> suitable for libraries, not headers, because they are paths relative to 
> lib/ such as ../lib64.)

If I understand correctly, Jakub wanted to have it working with -m32 being used
for 64-bit GCC compiler. So yes, multi os for header files.

So the question is what can we really do in the GCC driver?

Martin