This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.
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