Building Native ToolChain (SH3)

[Kristoffer Ericson]

Greetings,

gcc -v Information.

Reading specs from /usr/lib/gcc/sh3-unknown-linux-gnu/3.4.4/specs
Configured with: ./configure --host=sh3-unknown-linux-gnu --build=i686 
--enable-languages=c,c++ --prefix=/ : (reconfigured) ./configure 
--host=sh3-unknown-linux-gnu --build=i686 
--enable-languages=c,c++,ada,fortran --prefix=/ : (reconfigured) ./configure 
--host=sh3-unknown-linux-gnu --build=i686 
--enable-languages=c,c++,ada,f77,objc --prefix=/ : (reconfigured) 
./configure --host=sh3-unknown-linux-gnu --build=i686 
--enable-languages=c,c++ --prefix=/ : (reconfigured) ./configure 
--host=sh3-unknown-linux-gnu --build=i686 --enable-languages=c,c++ 
--prefix=/ : (reconfigured) ./configure --host=sh3-unknown-linux-gnu 
--build=i686 --enable-languages=c,c++ --prefix=/usr
Tread model: posix
gcc version 3.4.4

gcc --print-search-dirs information:

install: /usr/lib/gcc/sh3-unknown-linux-gnu/3.4.4/
programs: 
=/usr/libexec/gcc/sh3-unknown-linux-gnu/3.4.4/:/usr/libexec/gcc/sh3-unknown-linux-gnu/3.4.4/:
/usr/libexec/gcc/sh3-unknown-linux-gnu/:/usr/lib/gcc/sh3-unknown-linux-gnu/3.4.4/:
/usr/lib/gcc/sh3-unknown-linux-gnu/:/usr/lib/gcc/sh3-unknown-linux-gnu/3.4.4/
...........
...........
libraries: 
=/usrlib/gcc/sh3-unknown-linux-gnu/3.4.4/:/usr/lib/gcc-sh3-unknwon-linux-gnu/3.4.4/:
/usr/lib/gcc/sh3-unknown-linux-gnu/3.4.4/../../../sh3-unknown-linux-gnu/lib/sh3-unknown-linux-gnu/3.4.4/:
/usr/lib/gcc/sh3-unknown-linux-gnu/3.4.4/../../../sh3-unknown-linux-gnu/lib/

All those reconfigured stuff must be because i didnt do a distclean before i 
recompiled it (2-3 times?). Im guessing only the last line is valid 
(prefix=/usr)?

I understand im doing something wrong.

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