Bug in gen_addr_rtx() in gcc4.1?
On a system which supports 64-bit implementation but with TARGET_ILP32 ABI, like HPUX on ia64, the gcc-4.1 compiler generates incorrect code for the dejagnu test gcc.dg/tree-ssa/pr23386.c. The problem seems because that the gen_addr_rtx() in tree-ssa-address.c always returns Pmode rtx. On a TARGET_64BIT machine, Pmode is DImode. In this case, the following expression is dereferenced after tree-based transformation: *(index+offset) where index is an int variable (SImode) and offset is a constant. The call sequence in expr.c is: expand_expr_real_1() --> addr_for_mem_ref() --> gen_addr_rtx() --> memory_address() where memory_address() is to generate a necessary zero_extend rtl instruction to clean the upper 32bit of the returned address rtx from gen_addr_rtx() if the rtx is not in Pmode. Because the address rtx is in Pmode, no zero_extend instruction is generated, and the address is an illegal address. It seems for me the correct solution is to generate the address rtx in gen_addr_rtx() with the widest mode from the operands index and offset, not always in Pmode. Thanks, Charles
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-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 hunky-dory but when run from the Windows command prompt,
> it used to give a "_spawnvp: No such file or directory" error when one
> tried to compile something."
The difference is that MSYS automatically adds the "bin"
folder of MinGW to the PATH. On the Windows command prompt,
I was trying to execute "gcc" directly without having its
"bin" folder in the PATH - if I add that folder to the PATH,
things work fine again. In the problematic case, GCC is able
to find "cc1" but not "as":
- --- 8< ---
E:\src\tmp>d:\MiscAppz\MinGW\bin\gcc -v hello.c
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.1.0/configure --prefix=/mingw \
- --target=i686-pc-mingw32 --enable-languages=c,c++ \
- --disable-nls --disable-debug --enable-__cxa_atexit \
- --enable-threads=win32 --disable-win32-registry \
- --with-ld=/mingw/bin/ld.exe --with-as=/mingw/bin/as.exe
Thread model: win32
gcc version 4.1.0
d:/miscappz/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/cc1.exe \
- -quiet -v -iprefix d:\miscappz\mingw\bin\../lib/gcc/i686-pc-mingw32/4.1.0/ \
hello.c -quiet -dumpbase hello.c -mtune=pentiumpro -auxbase hello \
- -version -o D:\TEMP/ccWC.s
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "d:/MiscAppz/MinGW/i686-pc-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/include
d:/MiscAppz/MinGW/include
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/include
End of search list.
GNU C version 4.1.0 (i686-pc-mingw32)
compiled by GNU C version 4.1.0.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65462
Compiler executable checksum: ee311961bfecdede449f181caa4cf975
as -o D:\TEMP/ccI5.o D:\TEMP/ccWC.s
gcc: _spawnvp: No such file or directory
- --- 8< ---
(Long lines broken up manually.)
Note that I *had* specified "--with-as", but I was using
UNIX-y paths which are *not* translated by MSYS for shell
scripts (unlike "regular" programmes):
- --- 8< ---
/e/src/tmp > cat hello.c
#include
int main( int argc, char *argv[])
{
if(argc > 1)
printf( "argv[1]: %s\n", argv[1]);
return 0;
}
/e/src/tmp > gcc hello.c
/e/src/tmp > ./a.exe /mingw
argv[1]: d:/MiscAppz/MinGW
/e/src/tmp > cat scr.sh
#!/bin/sh
echo $*
/e/src/tmp > ./scr.sh /mingw
/mingw
- --- 8< ---
Note also that GCC's programme search path does not include
its own location for some reason:
- --- 8< ---
d:/miscappz/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/
d:/miscappz/mingw/bin/../libexec/gcc/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/libexec/gcc/i686-pc-mingw32/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/
/usr/libexec/gcc/i686-pc-mingw32/4.1.0/
/usr/libexec/gcc/i686-pc-mingw32/
/usr/lib/gcc/i686-pc-mingw32/4.1.0/
/usr/lib/gcc/i686-pc-mingw32/
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw
32/bin/i686-pc-mingw32/4.1.0/
d:/miscappz/mingw/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw
32/bin/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
i686-pc-mingw32/4.1.0/
d:/MiscAppz/MinGW/lib/gcc/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
- --- 8< ---
This is the more readable version of the "programs" section
of the output of "D:\MiscAppz\MinGW\bin\gcc -print-search-dirs".
See also PR bootstrap/22259:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22259
The curious thing is that I could not find the message
in gcc-patches corresponding to CGF's patch and I cannot
find out who defines USE_MINGW_MSYS.
In any case, all this has been overridden in mainline by
a series of patches from Jim Blandy and Mark Mitchell,
though I haven't bootstrapped GCC mainline on MSYS.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFETdPEYb1hx2wRS48RAtDvAJwIFIHe8LQUsFWD8BJ5H4HWlk6i/gCfQbnM
S872RVKUETmoMikS+ymG+30=
=7rQb
-END PGP SIGNATURE-
RE: adding nodes in a tree --(about function name mangling)
On 25 April 2006 04:22, sean yang wrote:
> I want to insert the instrumentation code no matter from what language the
> MPI subroutines are called.
> I think I can take care of C and Fortran by the following (psuedo) code, but
> how can i find the rule for c++ name mangling? are there many cases that I
> need take care of?
>
> if (TREE_CODE ( t ) == FUNCTION_DECL){
>
> if (( !strncmp (IDENTIFIER_POINTER(DECL_NAME (t) , "mpi_", 4) || (
> !strncmp (IDENTIFIER_POINTER(DECL_NAME (t) , "_mpi_", 5)) {
> //(1) handles case of C language; (2) handle the case of Fortran
> }
>
> }
Why not cut right through your mess and declare your function extern "C"?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Windows Unicode and GCC
On Mon, 24 Apr 2006 15:27:07 -0400, Nicolas De Rico wrote: > I would like to compile files created on Windows and encoded in > "Unicode" (UTF-8 or UTF-16). Microsoft puts a little header at the > beginning of files to indicate that they are UTF-16, UTF-8, etc. I > believe that this header is standard unicode btw, not an extension! Are you thinking of the byte order mark (BOM)? If so then this is a quirk of UTF-16 and is a Windows thing that many apps can't handle correctly ... UTF-8 should not have any headers at all and GCC should handle them fine. Try using some text editor to check it really is UTF-8. thanks -mike
Re: Windows Unicode and GCC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Hearn wrote: > On Mon, 24 Apr 2006 15:27:07 -0400, Nicolas De Rico wrote: >> I would like to compile files created on Windows and encoded in >> "Unicode" (UTF-8 or UTF-16). Microsoft puts a little header at the >> beginning of files to indicate that they are UTF-16, UTF-8, etc. I >> believe that this header is standard unicode btw, not an extension! > > Are you thinking of the byte order mark (BOM)? If so then this is a quirk > of UTF-16 and is a Windows thing that many apps can't handle correctly ... > UTF-8 should not have any headers at all and GCC should handle them fine. > Try using some text editor to check it really is UTF-8. Windows Notepad still inserts a BOM (0xEF 0xBB 0xBF) at the beginning of files encoded with UTF-8. See: http://www.microsoft.com/globaldev/getwr/steps/wrg_unicode.mspx http://en.wikipedia.org/wiki/Byte_Order_Mark Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETfs0Yb1hx2wRS48RAkvmAKCae/o9vD3doaDKD1VPOSUlSlhRjACdGqv0 nD0cMiSvZLu9TfmIf/BUuIU= =lZaM -END PGP SIGNATURE-
GCC 4.1 and R_PPC64_ADDR32 out of range
Hi, not such an high priority, but testing the latest gcc 4.1.0 in "whole system builds" I stumble over: jackd: error while loading shared libraries: /usr/lib64/libjack.so.0: R_PPC64_ADDR32 4056b70 for symbol `' out of range There only R_PPC64_ADDR32 in .text+0*. Any idea or proposal how to hunt this? Sincerely yours, -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rebe.name +49 (0)30 / 255 897 45
Re: GCC 4.1 and R_PPC64_ADDR32 out of range
Rene Rebe writes: > Hi, > > not such an high priority, but testing the latest gcc 4.1.0 in > "whole system builds" I stumble over: > > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0: > R_PPC64_ADDR32 4056b70 for symbol `' out of range > > There only R_PPC64_ADDR32 in .text+0*. > > Any idea or proposal how to hunt this? just a guess, but perhaps libjack isn't compiled -fPIC? Andrew.
Multiple calls to __gcov_init
Why does GCC emit multiple calls to __gcov_init, via mulitple (two) entries in
the ctors table? For example "int foo () { return 0; }" compiled with "gcc -S
-fprofile-generate" produces the following assembly file, where the ".ctors"
section conrtains two entries.
.file "x.c"
.text
.globl foo
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
movl.LPBX1, %eax
movl.LPBX1+4, %edx
addl$1, %eax
adcl$0, %edx
movl%eax, .LPBX1
movl%edx, .LPBX1+4
movl$0, %eax
popl%ebp
ret
.size foo, .-foo
.local .LPBX1
.comm .LPBX1,8,8
.section.rodata
.LC0:
.string "/home/velco/x.gcda"
.data
.align 4
.LC1:
.long 3
.long 970900823
.long 1
.align 32
.type .LPBX0, @object
.size .LPBX0, 52
.LPBX0:
.long 875573861
.long 0
.long -786236445
.long .LC0
.long 1
.long .LC1
.long 1
.long 1
.long .LPBX1
.long __gcov_merge_add
.zero 12
.text
.type _GLOBAL__I_0_foo, @function
_GLOBAL__I_0_foo:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movl$.LPBX0, (%esp)
call__gcov_init
leave
ret
.size _GLOBAL__I_0_foo, .-_GLOBAL__I_0_foo
.section.ctors,"aw",@progbits
.align 4
.long _GLOBAL__I_0_foo
.align 4
.long _GLOBAL__I_0_foo
.ident "GCC: (GNU) 4.2.0 20060425 (experimental)"
.section.note.GNU-stack,"",@progbits
Re: GCC 4.1 and R_PPC64_ADDR32 out of range
Hi, On Tuesday 25 April 2006 14:21, Andrew Haley wrote: > Rene Rebe writes: > > Hi, > > > > not such an high priority, but testing the latest gcc 4.1.0 in > > "whole system builds" I stumble over: > > > > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0: > > R_PPC64_ADDR32 4056b70 for symbol `' out of range > > > > There only R_PPC64_ADDR32 in .text+0*. > > > > Any idea or proposal how to hunt this? > > just a guess, but perhaps libjack isn't compiled -fPIC? Nope, it is. -- René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://exactcode.de | http://t2-project.org | http://rebe.name +49 (0)30 / 255 897 45
Re: Multiple calls to __gcov_init
On 4/25/06, Momchil Velikov <[EMAIL PROTECTED]> wrote:
> Why does GCC emit multiple calls to __gcov_init, via mulitple (two) entries
> in
> the ctors table? For example "int foo () { return 0; }" compiled with "gcc -S
> -fprofile-generate" produces the following assembly file, where the ".ctors"
> section conrtains two entries.
-funit-at-a-time fixes it. But who uses -fprofile-generate with -O0
these days...
Richard.
Re: Bug with SSE on mingw32
> I'm experiencing a strange gfortran bug, i686-pc-mingw32 specific, > with options -march=pentium4 -mfpmath=sse -msse. Some more input... the bug appears when SSE sqrtsd is called, but only if libgfortran contrusctors have been run: cat a.s .file "a.f90" .section .rdata,"dr" .align 8 LC0: .long 0 .long 1073741824 .text .globl _MAIN__ .def_MAIN__;.scl2; .type 32; .endef _MAIN__: pushl %ebp movl%esp, %ebp subl$16, %esp movsd LC0, %xmm0 movsd %xmm0, -8(%ebp) sqrtsd -8(%ebp), %xmm0 movsd %xmm0, -8(%ebp) leave ret $ gcc a.s -lgfortranbegin -lgfortran && ./a.exe [popus up crash dialog] $ diff a.s a_nolibgfortran.s 8,10c8,10 < .globl _MAIN__ < .def_MAIN__;.scl2; .type 32; .endef < _MAIN__: --- > .globl _main > .def_main; .scl2; .type 32; .endef > _main: $ gcc a.s && ./a.exe [works ok] The problem appears to be inside the libgfortran constructor and functions called herein. I'll try to narrow it, but I don't really know what to look for... What kind of code can be expected to generate such bad behaviour? FX
Re: Windows Unicode and GCC
Hi, Yes, I was talking about the byte order mark (BOM): http://www.unicode.org/faq/utf_bom.html It seems that BOM is a Unicode UTF facility that MS thought was a great thing to implement, and I certainly agree with that assessment. BOM tells even more than its name implies. A program can detect if a file is encoded in UTF-8, 16LE, 16BE, 32LE and 32BE in a very easy way. I think that it would be good for gcc (or cpp) to support this because it would make for better interoperability with Visual C++, and it would allow each file to indicate how it is encoded without having to rely on some setting that may or may not provide the correct information in every case. Nicolas Ranjit Mathew wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Hearn wrote: On Mon, 24 Apr 2006 15:27:07 -0400, Nicolas De Rico wrote: I would like to compile files created on Windows and encoded in "Unicode" (UTF-8 or UTF-16). Microsoft puts a little header at the beginning of files to indicate that they are UTF-16, UTF-8, etc. I believe that this header is standard unicode btw, not an extension! Are you thinking of the byte order mark (BOM)? If so then this is a quirk of UTF-16 and is a Windows thing that many apps can't handle correctly ... UTF-8 should not have any headers at all and GCC should handle them fine. Try using some text editor to check it really is UTF-8. Windows Notepad still inserts a BOM (0xEF 0xBB 0xBF) at the beginning of files encoded with UTF-8. See: http://www.microsoft.com/globaldev/getwr/steps/wrg_unicode.mspx http://en.wikipedia.org/wiki/Byte_Order_Mark Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://rmathew.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETfs0Yb1hx2wRS48RAkvmAKCae/o9vD3doaDKD1VPOSUlSlhRjACdGqv0 nD0cMiSvZLu9TfmIf/BUuIU= =lZaM -END PGP SIGNATURE-
Re: Windows Unicode and GCC
It seems that BOM is a Unicode UTF facility that MS thought was a great thing to implement, and I certainly agree with that assessment. BOM tells even more than its name implies. A program can detect if a file is encoded in UTF-8, 16LE, 16BE, 32LE and 32BE in a very easy way. I think that it would be good for gcc (or cpp) to support this because it would make for better interoperability with Visual C++, and it would allow each file to indicate how it is encoded without having to rely on some setting that may or may not provide the correct information in every case. cpp relies on libiconv for almost all of it's translation support. Try preprocessing a file with iconv and see if you can compile it afterwards. If you can, then it's a gcc bug, otherwise you'll need to bug the libiconv folks about implementing support. -eric
Re: GCC 4.1 and R_PPC64_ADDR32 out of range
On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> Rene Rebe writes:
> > Hi,
> >
> > not such an high priority, but testing the latest gcc 4.1.0 in
> > "whole system builds" I stumble over:
> >
> > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> > R_PPC64_ADDR32 4056b70 for symbol `' out of range
> >
> > There only R_PPC64_ADDR32 in .text+0*.
> >
> > Any idea or proposal how to hunt this?
>
> just a guess, but perhaps libjack isn't compiled -fPIC?
I further narrowed it stripping down the preprocessed sources. The
culprit appears to be a function pointer passed as reference to a thread
creation function:.
client.c:1696:
#else
if (jack_client_create_thread (client,
&client->thread,
client->engine->client_priority,
client->engine->real_time,
jack_client_thread, client)) {
return -1;
}
#endif
When the jack_client_thread is replaced with NULL the shared object can be
loaded, with jack_client_thread it yields the:
R_PPC64_ADDR32 402e240 for symbol `' out of range
The functions are declared as:
void *
jack_client_thread (void *arg)
and
int jack_client_create_thread (jack_client_t* client,
pthread_t *thread,
int priority,
int realtime,
void *(*start_routine)(void*),
void *arg);
Any idea?
--
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://exactcode.de | http://t2-project.org | http://rebe.name
+49 (0)30 / 255 897 45
Re: Windows Unicode and GCC
Hello and thank you for the reply. I created 3 files (very simple hello world program): hi.c: UTF-8 without BOM hi-8.c: UTF-8 with BOM hi-16.c: UTF-16 with BOM I ran iconv twice for each file. Once with the -f option which explicitly indicates the encoding, and once without the -f option to see if libiconv is able to detect the encoding from the BOM. In all cases I told iconv to create a UTF-8 file and I used od (octodump) to inspect the resulting file. My results: 1: without -f option 2: with -f option hi.c (1):UTF-8, without BOM hi.c (2):UTF-8, without BOM hi-8.c (1): UTF-8, with BOM * hi-8.c (2): UTF-8, with BOM * hi-16.c (1): illegal character error. Does not use BOM automatically! hi-16.c (2): UTF-8, without BOM Considering those results, it looks a bit like I'll have to bug the libiconv crew! Presumably, cpp wants everything from libiconv in UTF-8 with no BOM. Nick * Did libiconv really consider the BOM or did it just copy the file??? I have to investigate. libiconv may just not support the BOM at all! Eric Christopher wrote: It seems that BOM is a Unicode UTF facility that MS thought was a great thing to implement, and I certainly agree with that assessment. BOM tells even more than its name implies. A program can detect if a file is encoded in UTF-8, 16LE, 16BE, 32LE and 32BE in a very easy way. I think that it would be good for gcc (or cpp) to support this because it would make for better interoperability with Visual C++, and it would allow each file to indicate how it is encoded without having to rely on some setting that may or may not provide the correct information in every case. cpp relies on libiconv for almost all of it's translation support. Try preprocessing a file with iconv and see if you can compile it afterwards. If you can, then it's a gcc bug, otherwise you'll need to bug the libiconv folks about implementing support. -eric
Re: Multiple calls to __gcov_init
On Tue, Apr 25, 2006 at 03:05:26PM +0200, Richard Guenther wrote:
> On 4/25/06, Momchil Velikov <[EMAIL PROTECTED]> wrote:
> > Why does GCC emit multiple calls to __gcov_init, via mulitple (two)
> > entries in
> > the ctors table? For example "int foo () { return 0; }" compiled with "gcc
> > -S
> > -fprofile-generate" produces the following assembly file, where the ".ctors"
> > section conrtains two entries.
>
> -funit-at-a-time fixes it. But who uses -fprofile-generate with -O0
> these days...
gcov is used for coverage testing, and these are best run at -O0.
Re: GCC 4.1 and R_PPC64_ADDR32 out of range
Rene Rebe writes:
> On Tuesday 25 April 2006 14:21, Andrew Haley wrote:
> > Rene Rebe writes:
> > > Hi,
> > >
> > > not such an high priority, but testing the latest gcc 4.1.0 in
> > > "whole system builds" I stumble over:
> > >
> > > jackd: error while loading shared libraries: /usr/lib64/libjack.so.0:
> > > R_PPC64_ADDR32 4056b70 for symbol `' out of range
> > >
> > > There only R_PPC64_ADDR32 in .text+0*.
> > >
> > > Any idea or proposal how to hunt this?
> >
> > just a guess, but perhaps libjack isn't compiled -fPIC?
>
> I further narrowed it stripping down the preprocessed sources. The
> culprit appears to be a function pointer passed as reference to a thread
> creation function:.
>
> client.c:1696:
> #else
> if (jack_client_create_thread (client,
> &client->thread,
> client->engine->client_priority,
> client->engine->real_time,
> jack_client_thread, client)) {
> return -1;
> }
> #endif
ppc64 function pointers point to a function descriptor, which
specifies both the entry point and TOC for the function.
I'm guessing the problem may be with the desriptor, but I'll bow out
now to let the PPC experts answer.
Andrew.
Re: Windows Unicode and GCC
Presumably, cpp wants everything from libiconv in UTF-8 with no BOM. Yes. -eric
libstdc++ in a combined tree
Another one like libssp. In libstdc++-v3's configure.ac, we see this: # This depends on GLIBCXX CHECK_LINKER_FEATURES, but without it assumes no. GLIBCXX_ENABLE_SYMVERS([yes]) The comment lies. If we haven't yet checked the linker features, it will check them, and configure will fail in a combined build because newlib/libgloss hasn't yet been installed. Since we already check for cross compiling, I've been using this conditional instead: if test x"$gcc_no_link" = xyes; then true; else # This will run GLIBCXX CHECK_LINKER_FEATURES, so we can't use it if we can't # build executables. GLIBCXX_ENABLE_SYMVERS([yes]) fi but of course this will drop support for cross compiled linux targets having symbol versioning. Suggestions?
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
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 ("i686-pc-mingw32/bin") where you should install
the version of as.exe and ld.exe you want that installation of gcc to use.
Ross Ridge
C0ntent c0pu1ation
Chill out by visiting constantely http://vminimumf6.com > > celano which browkelmann without tableize > > milliseconds nullhang tfulness of dorso
Re: Crossed-Native Builds, Toolchain Relocation and MinGW
-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/i686-pc-mingw32/4.1.0/../../../../i686-pc-mingw32/bin/
>
> This is the directory ("i686-pc-mingw32/bin") where you should install
> the version of as.exe and ld.exe you want that installation of gcc to use.
Thanks for pointing this out - I knew this, but for some reason
it didn't strike me. What's happening is that I am using stock
binutils binaries as distributed by the MinGW project, but
compiling my own GCC binaries. The stock MinGW binutils (and
GCC) are built for the target "mingw32" (an alias for
i386-pc-mingw32) while I was building for the target
"i686-pc-mingw32".
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.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFETxdXYb1hx2wRS48RAl1mAJ9LGa+iqjfD3Om5WaiAynZd8O7iHACdHDHp
Lf9WkRN3Qi0WYeAMlMjq66M=
=MSnk
-END PGP SIGNATURE-
