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
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 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
-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 prefix
> but later moved to another location. The binaries appear to be checking
> som
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 prefix
but later moved to another location. The binaries appear to b
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
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
-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
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
b
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 ch
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 likely
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
15 matches
Mail list logo
