Re: GCC configure flags for 4.6.0

On 6/22/2011 12:39 PM, NightStrike wrote:
> On Sun, Jun 12, 2011 at 6:01 PM, Keith Marshall wrote:
>> On 08/06/11 15:38, Charles Wilson wrote:
>>> Ah, so that's what you meant: you *have* to use sys-root to avoid the
>>> problem.  I'm not sure that's the best solution...I'm not sure why, but
>>> /something/ about that bothers me.  It seems like taking a feature
>>> developed and intended for cross-compilers, and using it with a native
>>> compiler to take advantage of a side effect, is kinda kludgy.
>>
>> It bothers me too.  It isn't just kludgy; I distinctly recollect
>> Danny Smith telling us, when NightStrike suggested this before, that
>> it is dead wrong.
> 
> Why?

In another message in this thread, John E. (TDM) said this:
> Also, a sysroot-ed mingw32 GCC lacks one or two search paths that the
> current build uses -- <root>/include among them, IIRC.

Leaving out <INSTALL>/include from the search path seems to be a pretty
big issue, or am I missing something?

OTOH, I'd be perfectly happy to accept a compiler that ignored
<INSTALL>/local/include...

>> The build documentation for GCC tells us that --with-sysroot is an
>> option for use exclusively when building a cross-compiler.  When this
>> was previously pointed out to NightStrike, I also recollect that he
>> suggested that perhaps the documentation could be changed.  However, the
>> GCC maintainers have NOT changed the documentation, so I guess it is
>> still wrong to build a native compiler with sysroots.
> 
> The build docs have the sysroot options in the cross compiler section.
>  The options themselves, however, were designed outside that scope.
> The fact that you can ONLY build a relocatable toolchain by using a

ONLY? really?

> sysroot regardless of the target system exemplifies that.  I guess in
> a way what they do is just really extend the term "cross compiler" to
> be "any compiler that doesn't use /usr/local libs/headers".  And,
> really, this may be a valid interpretation.
> 
> At any rate, the docs didn't change because no one mentioned it to
> anyone who can change the docs, not for any other reason.  That
> doesn't change the fact that there is a single prescribed way to have
> a relocatable toolchain that doesn't rely on any hard coded paths --
> use sysroots <= prefix.
> 
>> I definitely do not think we should emulate this dodgy practice.

Well, if it's backed up by the gcc devs, and mingw.org's understanding
of the purpose/design of sys-root is flawed, then I wouldn't say it is
dodgy.

If the current upstream *implementation* of that design has bugs -- such
as missing *relative* include paths that a non-sysroot compiler would
have -- then it STILL isn't dodgy to use sys-root -- only risky, until
those upstream bugs are fixed.

OTOH, if mingw64's understanding is flawed, and mingw.org's is
correct...well, say what you will. 

> Good.  It makes us look better* :) :)
> 
> * according to our users...

Sigh.  You're doing it again, NS.

--
Chuck

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev