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 translati
-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
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
-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
-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:
> ...
>> d:/MiscAppz/MinGW/lib/gcc
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
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,
> everyth
shows how MSYS 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
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 wi
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.
Ross Ridge
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 is
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 is a native Win32 application and
can'
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 con
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 i
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
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.
Y
-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 "GC
Ranjit Mathew wrote :
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).
In this issue was something I didn't understand
-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 on
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 likely
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
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 ch
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
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
b
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Murphy wrote:
> Ranjit Mathew wrote:
>>
>> However, when I moved the binaries to another machine
>> where MinGW was installed in "D:\MinGW", the compiler was
>> not able to find the C runtime headers, even though the
>> folder structure was exactl
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 constants
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 inst
lib/gcc/arm-elf/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
ar to be checking
> 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=/mi
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
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 appear
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
> so
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 prob
34 matches
Mail list logo
