Hi,
I've been attempting to build the gcc-4.0 20050319 snapshot under
mingw/msys for arm-elf target with a few problems.
the mingw32 gcc is 3.4.2
Configuring seems to work fine.
../../$GCC_SRCDIR/configure \
--enable-languages=c,c++ \
--enable-interwork --enable-multilib\
--with-gcc --wi
E. Weddington wrote:
Dave Murphy wrote:
copying the compile line and removing the spurious -I and the
-I../../../gcc-4.0-20050319-new/gcc/ results in no errors.
I'm having a little trouble finding where this line is built up in
the makefiles, can anyone point me in the right direction to
Chris Garrett wrote:
I built 4.0.0 last week and thought I would update to 4.0.1. While
building 401 I got the following error:
--
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-protot
Hi,
I've been having some trouble building gcc 4.0.1 for mips target on a
mingw host
The build fails at this point
/c/projects/devkitPro/sources/psp/gcc/gcc/xgcc
-B/c/projects/devkitPro/sources/psp/gcc/gcc/
-Bc:/devkitPro/devkitPSP_4.0.1/psp/bin/
-Bc:/devkitPro/devkitPSP_4.0.1/psp/lib/ -is
Dave Korn wrote:
I've been having some trouble building gcc 4.0.1 for mips target on a
mingw host
No you aren't. You're using a modified version of the gcc-4.0.1 sources
and you're targetting PSP. That may be a MIPS backend, but it's a different
_target_.
:) fair enough, the patch
output of config.guess
$ gcc-4.1.0-20060219/config.guess
i686-pc-mingw32
$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../../gcc-4.1.0-20060219/configure
--enable-languages=c,c++ --with-cpu=arm7tdmi --enable-interwork
--enable-multilib --with-gcc --with-gnu-ld --with-
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
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 bin
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 appe
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
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
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
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
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
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 identi
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. MinG
Ross Ridge wrote:
Ross Ridge wrote:
That makes no difference. MinGW GCC is a native Win32 application and
can't see any mounts you create with MSYS.
Dave Murphy wrote:
sorry but you're most definitely wrong about that
No, I'm not. The example you gave
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,
includin
FX Coudert wrote:
Hi all, hi mingw32 maintainers,
I'm experiencing a strange bug building mainline as a native compiler
on i386-pc-mingw32 (with MSYS). It builds fine with the following
configure line:
../gcc/configure --prefix=/mingw --with-gmp=/home/coudert/local
--disable-nls --with-ld
Rask Ingemann Lambertsen wrote:
There are other targets with targets specific options to work around this or
that bug, quirk, defect or errata. In this case, why would two options
-mno-byte-writes and -mbyte-writes, with the latter being the default, be
unlikely to be acceptable? In particular, t
20 matches
Mail list logo
