Daniel Jacobowitz wrote:
On Sat, Apr 15, 2006 at 09:46:24AM +0100, Dave Murphy wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Here's another attempt at a patch which fixes the problem for me,
including the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ross Ridge wrote:
Ranjit Mathew wrote:
In the problematic case, GCC is able to find cc1 but not as ...
...
Note also that GCC's programme search path does not include
its own location for some reason:
...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ranjit Mathew wrote:
So now I only need to figure out why the cross-compiler
is not picking up headers from $PREFIX/$TARGET while
building a crossed-native compiler, even though it used
to do so in earlier releases.
This is misleading, so I
On Wed, Apr 26, 2006 at 06:29:46PM +0530, Ranjit Mathew wrote:
$SYSTEM_HEADER_DIR is supposed to be /mingw/include
for a native MinGW target (and since host == target, the
build is being considered native). However, in a crossed-
native build, I cannot have MinGW headers in this path, so
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Jacobowitz wrote:
On Wed, Apr 26, 2006 at 06:29:46PM +0530, Ranjit Mathew wrote:
$SYSTEM_HEADER_DIR is supposed to be /mingw/include
for a native MinGW target (and since host == target, the
build is being considered native). However, in a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Murphy wrote:
I'm totally at a loss to explain the problems Ranjit was experiencing in
this mail then.
http://gcc.gnu.org/ml/gcc/2006-04/msg00247.html
the part where he says when run from within the MSYS environment,
everything was
Ranjit Mathew wrote:
In the problematic case, GCC is able to find cc1 but not as ...
...
Note also that GCC's programme search path does not include
its own location for some reason:
...
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
This is the directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kai Ruottu wrote:
Because all the MinGW target libs already were produced during the step
1, it should
sound being reinventing the wheel to try to reproduce these during the
step 2
So one uses the 'make all-gcc', and gets only the GCC
Ranjit Mathew kirjoitti:
If I understand you correctly, you're saying that the
target runtime libraries are already created by the
cross-compiler in Phase 1, so I don't need to rebuild
them again in Phase 2 along with the crossed-native
compiler - I can get by by just building the compiler.
Kai Ruottu wrote:
Ranjit Mathew kirjoitti:
If I understand you correctly, you're saying that the
target runtime libraries are already created by the
cross-compiler in Phase 1, so I don't need to rebuild
them again in Phase 2 along with the crossed-native
compiler - I can get by by just building
Dave Murphy wrote:
When a mingw gcc toolchain is built on a linux host then it cannot find
it's headers or it's associated tools when running from a cmd shell on
the windows host. This can be worked around by using the msys shell to
provide a mount point identical to the configured prefix but
Ross Ridge wrote:
Dave Murphy wrote:
When a mingw gcc toolchain is built on a linux host then it cannot find
it's headers or it's associated tools when running from a cmd shell on
the windows host. This can be worked around by using the msys shell to
provide a mount point identical to the
Ross Ridge wrote:
Ross Ridge wrote:
MinGW GCC is a native Win32 application and is unaffected by any mounts
you create with MSYS.
Dave Murphy wrote:
It's affected when you run from the msys bash shell, my apologies for
not being clear.
That makes no difference. MinGW GCC
, which is not a native Win32 application. The toolchain
relocation code in MinGW GCC is unaffected by MSYS mounts you might
create, and so providing a mount point identical to the configured
prefix won't have any effect.
Ross Ridge
Dave Murphy wrote:
[EMAIL PROTECTED] /e
$ gcc /usr/local/test/test.c -o /usr/local/test/test.exe
[EMAIL PROTECTED] /e
$ /usr/local/test/test.exe
E:\msys\local\test\test.exe
[EMAIL PROTECTED] /e
$
As you can see the paths are translated by the shell before being passed
to windows
mounts have an effect on
the MSYS shell, which is not a native Win32 application. The toolchain
relocation code in MinGW GCC is unaffected by MSYS mounts you might
create, and so providing a mount point identical to the configured
prefix won't have any effect.
oops, that'll teach me to think a bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
It seems that toolchain relocation, especially for
crossed-native builds, seems to be broken in mainline
while it used to work for earlier releases. The situation
seems particularly bad for Windows (MinGW).
I build GCC regularly only
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use make install DESTDIR=e:/devkitPro to install it where
you actually want it.
Ross Ridge
Ross Ridge wrote:
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use make install DESTDIR=e:/devkitPro to install it where
you actually want it.
Doesn't help, it's still
Dave Murphy wrote:
Ross Ridge wrote:
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use make install DESTDIR=e:/devkitPro to install it where
you actually want it.
Doesn't
Daniel Jacobowitz wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Expected as much :)
You might want to play around with relocation on a non-MinGW-hosted
system, for comparison. Does that work better? If so, it's
On Sat, Apr 15, 2006 at 09:46:24AM +0100, Dave Murphy wrote:
I had a look through gcc.c and noticed that standard_exec_prefix and
standard_libexec_prefix are constants which refer to the configured
install path. gcc_exec_prefix and gcc_libexec_prefix are the equivalent
paths adjusted for
Hi Dave.
I hope you find and squash the relocation bug the right way,
but until then, perhaps you could use my cheezy program
that fixes embedded paths in gcc toolchains. It's at
http://kegel.com/crosstool/current/fix-embedded-paths.c
I haven't tested it on mingw toolchains, so some assembly may
H. J. Lu wrote:
It may be related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
Can you try
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01757.html
Tried that but no difference.
I had a look through gcc.c and noticed that standard_exec_prefix and
standard_libexec_prefix are
/4.1.0/../../../../arm-elf/lib/arm-elf/4.1.0/:
/usr/local/devkitPro/MOVED/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib/:
/usr/local/devkitPro/devkitARM/arm-elf/lib/arm-elf/4.1.0/:
/usr/local/devkitPro/devkitARM/arm-elf/lib/
FWIW, I have faced a different toolchain relocation problem
On Fri, Apr 14, 2006 at 09:00:14PM +0100, Dave Murphy wrote:
Ranjit Mathew wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Murphy wrote:
I've been having some odd problems with relocation of 4.x toolchains -
i.e. when a toolchain is configured, built and installed with one
Hi,
I've been having some odd problems with relocation of 4.x toolchains -
i.e. when a toolchain is configured, built and installed with one prefix
but later moved to another location. The binaries appear to be checking
something in the old location before reading from the new path.
The
On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote:
Hi,
I've been having some odd problems with relocation of 4.x toolchains -
i.e. when a toolchain is configured, built and installed with one prefix
but later moved to another location. The binaries appear to be checking
Daniel Jacobowitz wrote:
On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote:
Hi,
I've been having some odd problems with relocation of 4.x toolchains -
i.e. when a toolchain is configured, built and installed with one prefix
but later moved to another location. The binaries
On 4/13/06, Dave Murphy [EMAIL PROTECTED] wrote:
Daniel Jacobowitz wrote:
On Thu, Apr 13, 2006 at 03:49:43PM +0100, Dave Murphy wrote:
Hi,
I've been having some odd problems with relocation of 4.x toolchains -
i.e. when a toolchain is configured, built and installed with one prefix
something in the old location before reading from the new path.
I might be mistaken, but I think this is intentional behaviour.
FWIW, I have faced a different toolchain relocation problem
in the GCC 4.1.0 release on MinGW. I configured and built
GCC using --prefix=/mingw on one machine where /mingw
maps
31 matches
Mail list logo
