Re: [Bug pch/14400] Cannot compile qt-x11-free-3.3.0

[Geoff Keating <geoffk@apple.com>]

On Apr 3, 2004, at 7:38 PM, Ian Lance Taylor wrote:

> Geoffrey Keating <geoffk@apple.com> writes:
>
>> I think that PCH that fails on one case out of a thousand is better
>> than PCH that fails in one thousand cases out of one thousand.
>
> Any thoughts on how difficult it would be to, when a PCH can not be
> loaded at the correct address, skip the PCH and try for the original
> header files?  We'd want to issue a warning, but the result will still
> be better then a compiler crash, particularly since the crash will be
> awkward to work around without manually removing the PCH.  Of course,
> the result will not necessarily be equivalent--the original headers
> might not be present, or might have been modified since the PCH was
> created.

The primary difficulty that I see would be in documenting this, that is 
that the result is not convenient to use.  At the moment, the 
documentation for PCH describes everything that you need to do to use a 
PCH, and it's agreed that cases where it does not work are bugs.  
Adding an extra clause that says "oh, and even if you follow these 
rules, on some platforms the compiler might just decide it doesn't like 
your PCH" does not seem very helpful.  Especially if it doesn't come 
with a list of those platforms.

The other difficulty is that I'm not sure that you can always back out 
of the address-space allocation.  I would probably have to see a patch 
before I could say how difficult that might be.

Again, my experience is that on all unix-like platforms, you *can* 
always get a suitable chunk of address space in some fashion, if you 
try hard enough.  For example, HP-UX was quoted as an OS on which it is 
difficult to do this, yet with less than ten minutes' searching the 
web, I found 
<http://docs.hp.com/hpux/onlinedocs/5965-4642/5965-4642.html> which 
seems to give sufficient information under 'Space apportioned to a 
Process"; apparently on HP-UX 10.x in 32-bit mode, data lives beween 
0x40000000 and 0x7fffffff, with a default stack size of 80Mb, so 
probably mapping the PCH so that its end was at 0x6fffffff would work.

-- 
Geoff Keating <geoffk@apple.com>