* Help building a mipsel-r3000-elfl compiler @ 2000-10-06 6:08 Tom Wilson 2000-10-06 9:40 ` Kai Ruottu 0 siblings, 1 reply; 4+ messages in thread From: Tom Wilson @ 2000-10-06 6:08 UTC (permalink / raw) To: crossgcc 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Help building a mipsel-r3000-elfl compiler 2000-10-06 6:08 Help building a mipsel-r3000-elfl compiler Tom Wilson @ 2000-10-06 9:40 ` Kai Ruottu 2000-10-06 10:04 ` Tom Wilson 0 siblings, 1 reply; 4+ messages in thread From: Kai Ruottu @ 2000-10-06 9:40 UTC (permalink / raw) To: Tom Wilson; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Help building a mipsel-r3000-elfl compiler 2000-10-06 9:40 ` Kai Ruottu @ 2000-10-06 10:04 ` Tom Wilson 2000-10-07 16:13 ` Kai Ruottu 0 siblings, 1 reply; 4+ messages in thread From: Tom Wilson @ 2000-10-06 10:04 UTC (permalink / raw) To: karuottu; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Help building a mipsel-r3000-elfl compiler 2000-10-06 10:04 ` Tom Wilson @ 2000-10-07 16:13 ` Kai Ruottu 0 siblings, 0 replies; 4+ messages in thread From: Kai Ruottu @ 2000-10-07 16:13 UTC (permalink / raw) To: Tom Wilson; +Cc: crossgcc 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-10-07 16:13 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-10-06 6:08 Help building a mipsel-r3000-elfl compiler Tom Wilson 2000-10-06 9:40 ` Kai Ruottu 2000-10-06 10:04 ` Tom Wilson 2000-10-07 16:13 ` Kai Ruottu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).