This is the mail archive of the crossgcc@sources.redhat.com 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]

Re: Newlib-1.9.0 doesn't build for PPC (target libsim.a)


"Bertin, Philippe" wrote:
> 
> Hi David, Hi all (again),
> 
> >   As Kai discovered earlier, powerpc-elf means SysV - a variety of desktop
> > Unix workstation - not a bare board.  You *must* use powerpc-eabi for the
> > embedded system you wish to use.  If I understand correctly (which is not
> > sure!), powerpc-eabi will use libnosys nstead of libsim, and your problem
> > should go away.
> >
> I hadn't understood Kai's earlier remark (and your remark on that one
> neither, David --> I have to say that I didn't find config.gcc ?) (see my
> former thread on this list for those entering right here).

 The target templates in the script 'gcc-2.95.3/gcc/configure' were moved into
the 'gcc/config.gcc' in gcc-3.0.x, so the name was false for gcc-2.95.3, sorry
for not mentioning this...
 
> After having looked into the EABI document (not understanding it all and
> fully :-(  ), and after safely having switched target (restarting from
> binutils, although binutils could eventually have been skipped ?), I still
> encounter that same problem at the same point.

 I would suspect the used 'make'...

> What is this libsim (simulation) library exactly doing, and is it necessary ?

 It provides the interface ('glue') routines for the PowerPC-simulator, 'psim',
which is built-in in a GDB for 'powerpc-eabi*', and as an stand-alone 'psim' or
'powerpc-eabi-run' executable, after building GDB or Insight. The 'psim' enables
one at least to run simple PowerPC-programs on the host without any target HW
yet. It has also some simulated I/O HW, not only the CPU... Please see the psim
docs in 'ftp://sources.redhat.com/pub/binutils/ppc-doc' (or something)

 Bettering the psim 'emulations' could be motivated, currently the psim docs say :

------------ clip -----------------------
Emulated Environments

BUG -- Motorola's embeded firmware BUG interface
OpenFirmware -- IEEE Standard for Boot (Initialization Configuration) Firmware.
NetBSD -- Emulation of user programs for NetBSD/PPC
Solaris -- Emulation of user programs for Solaris/PPC
Linux -- Emulation of user programs for Linux/PPC
------------ clip -----------------------

but while the first two may work, the last three are questionable... When one
tries to run a simple statically linked Linux/PPC executable under psim, it
fails with a 'unknown syscall' quite soon, the 'check the PPC-environment'-
syscall ('personality()' ?) is the first reason... So adding more emulated
syscalls would enable one to run simple Linux/PPC-programs in an simulated
'Linux/PPC' environment...

> Could I eventually safely take the fstat.o (and the other .o- files) and
> copy it into the rs6000 library before letting "powerpc-eabi-ar" do it's job
> with it ?

 Basically you should get the 'fstat.o' etc. into your libs. Their sources
are in the main 'libgloss' source directory and the produced Makefile should
take them and compile them into the build 'libgloss/rs6000' directory. But
somehow it didn't work...

 My advice would be to track the build by verbosely following what the 'make'
does ('-d') or get a log-file... Or try the GNU make (probably prebuilt in
'www.sunfreeware.com'), if now using the native 'make'.

 One choice is of course ask someone with a speedy net connection to email
the prebuilt 'powerpc-eabi' libs (from newlib-1.9 sources). 13 Mbytes stripped
(no debug info in them) and unpacked, so perhaps 5 Mbytes or more as packed...

 Or to find out whether any prebuilt 'powerpc-eabi' toolsets exist on the net,
'www.altivec.org' or something... The C-libraries and headers for a target are
host-independent, but of course target-dependent...

 Sometimes the result, for instance: "getting newlib-1.9 binaries, built for
'powerpc-eabi'", is more important than the method "getting newlib-1.9 binaries,
built for 'powerpc-eabi', on a specific host", sometimes not...

 I remember someone asking help with building glibc for some target under
Cygwin after just doing the same thing under Linux... And then asking help
in this 'reinventing the wheel'-project, but not being asked why on earth he
wanted to build the glibc again for the same target, but on another build host.
Ok, I found the message from my archives:

-------------------------- clip ------------------------------------------
> I am trying to make an powerpc-linux cross compiling environment on cygwin
> I compiled binutils, gcc, linux and glibc with the following procedure
 <snip>
> I think this is the bug of powerpc-linux-gcc compiled for cygwin host
> bucause on linux machine it compiled well.
-------------------------- clip ------------------------------------------

 Should things as obvious as the 'host-independency' of the target libs be told
in the Cross-GCC FAQ ?  Perhaps the person never got the Cygwin-hosted toolkit
ready because not knowing that just copying the already built 'powerpc-linux'
target libs from the Linux host would have been enough...

 I have seen several times people having problems with the newlib-build under
Windows/Cygwin, but don't remember seeing a case with the Solaris2 build host.
But some problems with the native Solaris2 'make' not working with some builds
I remember to being reported...

 If you are in a hurry, my advice would be to ask someone to email the powerpc-
eabi target libs or to put them temporalily somewhere for download. Unfortunately
I cannot do this easily... Later you can wonder why the build doesn't work and
to try to get it working...

 As the current 'www.ocdemon.com' case shows, their 'arm-elf' and 'powerpc-eabi'
toolchains (for Windows, Linux, Solaris2,...?) come without any libs, so someone
'contributing' these toolchains with prebuilt newlibs wouldn't be a bad idea...
Quite many may need those 'wiggler.dll's etc., although trying proudly to build
everything else from scratch...

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]