Help building a mipsel-r3000-elfl compiler

Help building a mipsel-r3000-elfl compiler

[Tom Wilson]

Hello,

I am attempting to build a cross compiler, from host i586-pc-linux-gnu to 
mipsel-r3000-elfl.  I don't seem to be having any luck.  Has anyone else 
managed to get this working?

I am using redhat 6.2 with gcc 2.96.2...(experimental compiler)  (I also 
tried this using gcc 2.95.2 to no avail)

I am using the source code for gcc 2.96.2 (and have also tried with 2.95.2)
I don't have any special mipsel-r3000-elfl stuff set up any where it is 
just a clean redhat install
with the compiler source in my home directory.

The steps I have taken so far are:

1)built a i586-pc-linux-gnu version of the binutils 2.9.5 (just to update 
my system)
2)built i586-pc-linux-gnu host to mips-r3000-elfl binutils with 
--prefix=/usr/local/mips-r3000-elfl
3)configured  gcc 2.96.2... thus:

--target=mipsel-r3000-elfl
--prefix=/usr/local/mipsel-r3000-elfl

(as recommended by faq)

That went ok...

I try to build using make all but get various problems along the way, 95% 
of which are just sym link problems.  I acn get as far as the test stage of 
the build then get an error message about the newly built compiler not 
producing execututables.


The aim of this is to build libstdc++v3 for the mips target.

thanks for any help

Tom.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Help building a mipsel-r3000-elfl compiler

[Kai Ruottu]

Tom Wilson wrote:

> 2)built i586-pc-linux-gnu host to mips-r3000-elfl binutils with
> --prefix=/usr/local/mips-r3000-elfl
> 3)configured  gcc 2.96.2... thus:
> 
> --target=mipsel-r3000-elfl
> --prefix=/usr/local/mipsel-r3000-elfl
> 
> (as recommended by faq)

 Cannot believe... Did the FAQ really say that you are allowed or
recommended to use different names for the install root, '--prefix=...' ?
Or was this just a typo?

> That went ok...
> 
> I try to build using make all but get various problems along the way, 95%
> of which are just sym link problems.

 The rule which the FAQ should have told is that the installation of the
target stuff happens under the $prefix/$target, so if you use a different
values for the '--prefix=...'es, the binutils stuff will be installed into
a place where GCC cannot find it... I remember you having problems with the
'xgcc' not finding the target 'as', because you used the default prefix
(/usr/local) for binutils and something else for GCC...

> I acn get as far as the test stage of the build then get an error message
> about the newly built compiler not producing execututables.

 Please explain which kind of system you think the 'mipsel-r3000-elfl' to
be ?  Ok, a R3000-compatible CPU and little-endian ELF object format but
what is the opsys or the I/O-structure in your board ?  Where does your
'Hello World' write the message? And what is the memory layout for your
executables?

  When you have these things clear, you perhaps will find the glue libraries
for the supported MIPS-boards, select someone of them for the extra one for
linking, besides only the 'libc.a', then select the linker script for the
same board and get the memory layout from it. When everything is set for
a known target, then the compiler can produce executables for it. The default
settings are in the 'specs' file ('.../gcc/specs' during the build) and the
essential specs are the '*link:' and the '*lib:'. To the first you add the
linker script name and to the second the glue library name. Something like:

----------------------------- clip ----------------------------------------
*link:
%{G*} %{EB} %{EL} %{mips1} %{mips2} %{mips3} %{mips4} %{bestGnum} %{shared}
%{non_shared} %(linker_endian_spec) -T idt.ld%s

*lib:
-lc -lidt -lc

*libgcc:
----------------------------- clip ----------------------------------------

 Although the link-spec is wrapped here, it should be on a single line! No
extra lines between the specs, just one empty line... The IDT-board stuff
was used here, the 'libidt.a' and 'idt.ld' come with (the built) newlib.
The link- and lib-specs will appear on the same 'ld' command line, so you
could put the linker script name on the lib-spec too... The '-lc' appears
twice because it can be possible that the 'libidt.a' needs still something
from 'libc.a'. The GNU ld cannot step backwards and take something from an
already scanned library...

 After the build has succeded, you can remove the default target settings,
or replace them with your own ones.

> The aim of this is to build libstdc++v3 for the mips target.

 Just tell what happens... I remember the 'mipstx39-elf' (probably also the
'mipstx39el-elf') working with C++, but not 'mips-elf' (or 'mipsel-elf') if
built from the gcc-2.95.2 sources... Your mystic 2.96.2 can work or not...


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Help building a mipsel-r3000-elfl compiler

[Tom Wilson]

At 19:42 06/10/2000 +0300, you wrote:
>Tom Wilson wrote:
>
> > 2)built i586-pc-linux-gnu host to mips-r3000-elfl binutils with
> > --prefix=/usr/local/mips-r3000-elfl
> > 3)configured  gcc 2.96.2... thus:
> >
> > --target=mipsel-r3000-elfl
> > --prefix=/usr/local/mipsel-r3000-elfl
> >
> > (as recommended by faq)
>
>  Cannot believe... Did the FAQ really say that you are allowed or
>recommended to use different names for the install root, '--prefix=...' ?
>Or was this just a typo?

I don't want to mess with the current compiler i.e use two versions.

> > That went ok...
> >
> > I try to build using make all but get various problems along the way, 95%
> > of which are just sym link problems.
>
>  The rule which the FAQ should have told is that the installation of the
>target stuff happens under the $prefix/$target, so if you use a different
>values for the '--prefix=...'es, the binutils stuff will be installed into
>a place where GCC cannot find it... I remember you having problems with the
>'xgcc' not finding the target 'as', because you used the default prefix
>(/usr/local) for binutils and something else for GCC...
>
> > I acn get as far as the test stage of the build then get an error message
> > about the newly built compiler not producing execututables.
>
>  Please explain which kind of system you think the 'mipsel-r3000-elfl' to
>be ?  Ok, a R3000-compatible CPU and little-endian ELF object format but
>what is the opsys or the I/O-structure in your board ?  Where does your
>'Hello World' write the message? And what is the memory layout for your
>executables?

It doesn't actually matter this compiler will never be actually used on a 
real target.  I am building this so that I can get a Makefile for 
libstdc++v3 which I can then mess with so that it will build for a 
comparable target under a Win32 host.  It may seem  a long way round or a 
silly thing to do, but not from where I'm sitting.

I just need a working compiler so that all the libstdc++v3 config scripts 
don't bomb out ahlfway through.

If you have a better suggestion then I would appreciate the help.



>   When you have these things clear, you perhaps will find the glue libraries
>for the supported MIPS-boards, select someone of them for the extra one for
>linking, besides only the 'libc.a', then select the linker script for the
>same board and get the memory layout from it. When everything is set for
>a known target, then the compiler can produce executables for it. The default
>settings are in the 'specs' file ('.../gcc/specs' during the build) and the
>essential specs are the '*link:' and the '*lib:'. To the first you add the
>linker script name and to the second the glue library name. Something like:

Any old glue libraries that would work, will do.

Where do I get them?

><snip>
>
> > The aim of this is to build libstdc++v3 for the mips target.
>
>  Just tell what happens... I remember the 'mipstx39-elf' (probably also the
>'mipstx39el-elf') working with C++, but not 'mips-elf' (or 'mipsel-elf') if
>built from the gcc-2.95.2 sources... Your mystic 2.96.2 can work or not...


The mystic 2.96.2 was a typo I am actually using gcc 2.96-20000731 
(experimental) the dot between 2.96 and 2 was a slip of the keyboard.

Thanks for your help

Tom.




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: Help building a mipsel-r3000-elfl compiler

[Kai Ruottu]

Tom Wilson wrote:
> 
> I don't want to mess with the current compiler i.e use two versions.

 After experimenting I may have had three or more versions for the same
target... Ok, the 'make install' uses always the same names unless one
uses the '--program-prefix=...' or '--program-suffix=...' to vary the
'gcc', 'g++' etc. names. My habit has been to use a install-script template
and edit it, ie. install 'manually' with a script. Anyway changing the
install prefix shouldn't be necessary.
> 
> It doesn't actually matter this compiler will never be actually used on a
> real target.
> 
> I just need a working compiler so that all the libstdc++v3 config scripts
> don't bomb out ahlfway through.
> 
> Any old glue libraries that would work, will do.
> Where do I get them?

 The easy way is to build the Cygnus newlib for the C-library and then also get
the glue libs from the build... I don't remember any easy-to-use prebuilt MIPS-
libs anywhere, e.g. the 'www.algor.co.uk' SDE-libs require messing with the
startups.

> The mystic 2.96.2 was a typo I am actually using gcc 2.96-20000731
> (experimental) the dot between 2.96 and 2 was a slip of the keyboard.

 When the egcs/gcc-snapshots have been broken for almost everything so far I
remember, I expected the RedHat7's  'gcc-2.96' being some kind of 'bug-fixed'
and working release from the snapshots... It didn't work with the H8/300 target
for which I tried it first... Probably it is just the egcs-20000731 snapshots
and all the time and money used for the download (15 Mbytes with a modem) was
really vain... Of course I had downloaded the snapshots-diffs once a week and
it isn't funny to get just the same garbage again...

 When the 'mips-linux' is one of the Linux'es (but does RedHat support it?),
perhaps it could work for 'mips*' targets....

 Hmmm, I built the snapshots for 'mips-elf' (32-bit  default) in Dec 11, 1999,
and I'm quite sure they didn't work very well because I haven't tried them
later for this target...

 For all current GCCs my conclusion is that the 64-bit default might work
much better, ie. using 'mips64*-elf' as the target name and using the '-mips1'
when compiling for R3000, should work much better than doing it vice versa...

Cheers, Kai



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com