-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 23, 2006 3:57 PM
To: Andrew Pinski
Cc: Mark Mitchell; Carlos O'Donell; gcc@gcc.gnu.org
Subject: Re: Searching configured and relocated prefix.
Andrew Pinski [EMAIL PROTECTED] writes:
On Jul 23, 2006
Andrew Pinski wrote:
On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote:
We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be searching
both directories?
Yes because someone might have just relocated the compiler
Mark Mitchell [EMAIL PROTECTED] writes:
1. If we search both locations (i.e., for a relocated compiler, search
the configured-time prefix and the installation-time prefix), we get the
following set of problems:
...
2. If we search only location (i.e., for a relocated compiler, search
only
On Jul 23, 2006, at 10:44 AM, Ian Lance Taylor wrote:
However, I think it's clear that the problems in (1) are more severe
than the problems in (2), on several grounds:
Me too.
I actually think the problems with 1 (b) are artificial and should not
be taken into account. I actually depend
Andrew Pinski wrote:
I actually think the problems with 1 (b) are artificial and should not
be taken into account.
This is not a hypothetical or artificial issue -- as I said, all three
problems I listed have been encountered by real users.
I actually depend on a common sysroot already
and
Yes, that's clever. But, you can create a symbolic link to the
sysroot
from each installation with a single command. And, your installer for
third-party developers can do that for you.
What are the equivalent to symbolic links on Windows and I am not
talking about
cygwin either?
(1b) If the configure-time prefix does not exist, but is under an NFS
mount, the compiler will cause automount traffic, NFS timeouts, etc.
...
However, I think it's clear that the problems in (1) are more severe
than the problems in (2), on several grounds:
I actually think the problems
Andrew Pinski wrote:
Yes, that's clever. But, you can create a symbolic link to the sysroot
from each installation with a single command. And, your installer for
third-party developers can do that for you.
What are the equivalent to symbolic links on Windows and I am not
talking about
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and the developer-base there is often
less
used to GNU software,
Andrew Pinski wrote:
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and the developer-base there is often less
On Jul 23, 2006, at 10:44 AM, Ian Lance Taylor wrote:
Me too.
Except now you have suggested that we change the current behavior
which you already suggested at the GCC summit we should not do at
least not for a couple of release for warning people. You cannot
have it both ways, people
On Sun, Jul 23, 2006 at 11:40:38AM -0700, Andrew Pinski wrote:
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and
On Jul 23, 2006, at 11:48 AM, Mark Mitchell wrote:
Are you suggesting that we ship software that performs poorly on
one of
the most popular systems actually in the field because, in the
abstract,
those systems could be better?
Maybe we just have to force the issue on people. As I
Andrew Pinski wrote:
On Jul 23, 2006, at 11:48 AM, Mark Mitchell wrote:
Are you suggesting that we ship software that performs poorly on one of
the most popular systems actually in the field because, in the abstract,
those systems could be better?
Maybe we just have to force the issue
On Sunday 23 July 2006 19:40, Andrew Pinski wrote:
Before Vista, there's no solution short of cp. However, you still
have the --sysroot command-line option. And, if you're worried about
Windows, see Paul's response; the problems I've described are
particularly bad on Windows, and the
Mark Mitchell wrote:
Sent: Monday, July 24, 2006 4:59 AM
Andrew Pinski wrote:
On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote:
We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be
searching both
Daniel Jacobowitz [EMAIL PROTECTED] writes:
[...]
| I think that in stage 1, we should switch to not searching any of the
| configured paths in favor of the relocated paths. Carlos has been
| working on patches for this. I'm sure it will break a few
| unexpected configurations. When it does,
Yes, that's clever. But, you can create a symbolic link to the
sysroot from each installation with a single command. And, your
installer for third-party developers can do that for you.
Beware - the linker expands symlinks to determine if a library comes
from the sysroot or not. It affects
On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote:
We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be searching
both directories?
Yes because someone might have just relocated the compiler but not
the rest of
the
GCC,
We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be searching
both directories?
Does anyone see a need to search *both* the configured prefix and the
relocated prefix? You can end up finding things you don't mean to
20 matches
Mail list logo
