This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Best wishes Kristoffer Ericson
From: Kai Ruottu <karuottu@mbnet.fi> Reply-To: karuottu@mbnet.fi To: crossgcc@sources.redhat.com Subject: Re: Building Native ToolChain (SH3) Date: Thu, 11 Aug 2005 12:08:41 +0300
Dan Kegel wrote:Kristoffer Ericson wrote:
Greetings,
I started experimenting with the prefix settings once i started having crt1.o
issues. I appreciate the information although a simple "use --prefix=/usr"
would have been just fine.
You'll just have to get used to Kai. He's very opinionated and verbose,
Ok, here comes my corrected opinion:
As the matter of fact I would like to see a native GCC for something like 'sh3-linux-gnu' being quite similar with any cross-GCC for this target !
But the Linux people long time ago decided that on Linux there is a imaginary proprietary native 'cc' whose install directories for headers and libraries the native GCC must mimic ! Also the Cygwin and MinGW people have decided similarly... I have never understood why these decisions were so obligatory.
Nothing should force a GCC for an Unix-like system to use just the '/usr/include', '/lib' and '/usr/lib'. A GCC for Linux could have used anything and as long as the existing sources tried to use these directories directly, instead of letting GCC to find any stuff automagically, these 'native directories' could have been only links or symlinks to where the stuff really is. Them being in a cross-GCC like install scheme should have been the natural choice.
If Windoze requires its DLLs normally in '\windows\system32' and Linux requires its '.so's in '/lib' and '/usr/lib', so what this has to do with the link-time issues, other than also these shared libs must be seen by the linker ? Getting them symlinked into the '$prefix/$target/lib' or something cannot be any rocket science
For the people who mainly cross-produce stuff, a cross-GCC for their (not so quick) Linux target system should be more familiar. Just as a cross-GCC for MinGW sounds as the natural choice when needing to produce something for the Windoze host. If some day one must produce the native GCC, producing it being different from the familiar GCC, doesn't sound sane at all. And then one can get from the native GCC :
F:\usr\local\bin>cpp-i686-mingw-32 -v
Reading specs from f:/usr/local/lib/gcc-lib/i686-mingw32/3.2.3/specs
Thread model: single
gcc version 3.2.3 (MinGW patched) (by karuottu@mbnet.fi)
f:\usr\local\lib\gcc-lib\i686-mingw32\3.2.3\cpp0.exe -lang-c -v -iprefix f:/usr/local/lib/gcc-lib/i686-mingw32/3.2.3/ -DWINNT -D__WINNT__ -D__WINNT -Asystem=wi
nnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i38
6 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ -D__tune_pentium2__ -D__tune_
pentium3__ -D__MINGW32__ -D_WIN32 -D__MSVCRT__ -D__stdcall=__attribute__((__stdc
all__)) -D__cdecl=__attribute__((__cdecl__)) -D__fastcall=__attribute__((__fastc
all__)) -D_stdcall=__attribute__((__stdcall__)) -D_cdecl=__attribute__((__cdecl_
_)) -D_fastcall=__attribute__((__fastcall__)) -D__declspec(x)=__attribute__((x))
-
GNU CPP version 3.2.3 (MinGW patched) (cpplib) (80386, BSD syntax)
ignoring nonexistent directory "NONE/include"
#include "..." search starts here:
#include <...> search starts here:
f:/usr/local/include
f:/usr/local/lib/gcc-lib/i686-mingw32/3.2.3/include
f:/usr/local/i686-mingw32/sys-include
f:/usr/local/i686-mingw32/include
/usr/local/include
/usr/local/lib/gcc-lib/i686-mingw32/3.2.3/include
/usr/local/i686-mingw32/sys-include
/usr/local/i686-mingw32/include
End of search list.
No any weird 'native' directories used at all...
So generally Kristoffer is free to produce any kind of "unnormal" native GCC... My point only was to say that maybe practicing with a "normal" native GCC first could be useful... Not that I in any way would prefer the native install scheme !
The clue for producing a native GCC as a cross-GCC like GCC is using different name for the host and target, for instance using
--host=sh3-linux-gnu --target=sh3eb-linux-gnu
(if the 'sh3' means the same as 'sh3eb') could enable this. In the x86 world a 'i586' is different from 'i686' and these things are easy...
------
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |