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
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
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
-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
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
15 matches
Mail list logo
