Re: Building Native ToolChain (SH3)

[Kai Ruottu <karuottu at mbnet dot fi>]

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