Re: linking newlib (libc.a crt0.o) for powerpc-ibm-eabi target on i686-pc-cygwin host

["J. Johnston" <jjohnstn at cygnus dot com>]

Tony, 

  Let's start with some fundamentals.  The newlib C library sits upon a
small set of low-level system routines.  These are read, write, open, close,
_exit, plus a few others.  They are not generally built with newlib and
are left to be supplied by a separate library.  If you will notice, there is
a libgloss component shipped with newlib which builds such libraries for
certain ports.

  Now, the low-level routines are very board-specific.  You have to determine
where you want the code to run.  Many libgloss ports only provide support for
running on the simulator.

  In some cases, libgloss ports build multiple low-level libraries including versions
that are targetted for evaluation boards, etc..  If you look in the libgloss/rs6000
directory, you can look at the Makefile.in file to see the various libraries that
get built for the powerpc.  In addition to the simulator library, there are ads,
mvme, mbx, and yellowknife libraries.  If any of these match where you intend to run
your code or are compatible, you are in business.  Otherwise, you will either have to 
write your own version of libgloss suited to your particular board or you will have
to find a board support package out there.  There is a special libnosys.a built
which supports sbrk and stubs all the remaining functions to fail.  This can be
used if your application does not need to do I/O.  A crt0 and _exit routine are
not supplied by libnosys which is generic C code.

  For the powerpc, the compiler has built-in knowledge of the various libgloss libraries 
and makes it easy for you via -m compiler options.  If you specify -msim, the compiler 
links in newlib over top the simulator libgloss.  Similiarly, you could specify -mads, 
-mmvme, or -myellowknife.  There is also an mbx library that is not tied directly to a compiler
option, but you can access it if you need to.  

  In your note below you state that -msim does not link in a crt0 or newlib.  This is not true.  
You link in newlib plus a special crt0 and low-level routines tailored for the simulator.  
This is done under the covers for you. If you want to see what the compiler is doing for you, 
specify the -v compiler option.  For example, if you compile -v -msim you will see that -lsim 
gets specified for you.

  Another problem you ran into had to do with how linking works on Unix.  Be aware that
Unix linking is position-dependent on the command line and goes from left to right.
If you specify a library in the command (e.g. -lc), it will search the library for any 
unresolved symbols at that point in the command.  If you add subsequent objects or 
libraries after the -lxxx specification and they need items from libxxxc, the linker
will not back-track for you;  you have to specify -lxxx again.  Thus, it is usually
the case that you leave your library specification after all source and object files.
When you specified your test case last, it created an object file that needed printf, etc..
When the linker processed your -lc specification, there were no unresolved symbols at that
point.  Had you put -lc after your source file, you would have at least got printf.
Now, since printf will eventually need items from the libgloss library, you would
have still gotten a failure.  You could have added -lsim or whatever to fulfill this.
I should note that there is an option to group a set of libraries and to repeatedly
search the list until there are no unresolved entries.  This helps in the case where
libraries have interdependencies and saves you having to specify them over and over
again.

  If you need to write your own libgloss, you might consider looking at the mbx
code in the libgloss/rs6000 directory.  It has a compiler spec file which specifies
an ld script and the libraries to link in.

  I hope this helps.

-- Jeff J.

> On Thu, Sep 13, 2001 at 05:11:19PM -0400, Anthony P Ferranti wrote:
> > I am experiencing problems when cross-compiling programs with GCC that
> > involve a linking stage.  I believe they are related to the library
> > "libc.a" and the startup file "crt0.o".  It is my understanding that these
> > files are installed with newlib and they appear to be present.  This
> > appears to be the same problem Dan Alderman experienced on Feb 12, 2001 and
> > posted to this mailing list.  Dan, if you could remember how you solved
> > this problem your help would be greatly apprecieated.  I am new to the UNIX
> > environment and C-programming.  Building GCC as a cross-compiler has been
> > my first project so I'm a bit confused.  I've tried reading all the FAQs
> > and mailing lists to no avail.  Any help is greatly appreciated.
> >
> > Here is what I did to install an i686-pc-cygwin hosted powerpc-unknown-eabi
> > cross-compiler in "/usr/local".  Source files were unpacked into
> > "/usr/local/src".  Packages were built in "/usr/local/obj"...
> >
> >
> > cygwin$  host=i686-pc-cygwin
> > cygwin$  build=$host
> > cygwin$  target=powerpc-unknown-eabi
> > cygwin$  prefix=/usr/local
> > cygwin$  srcroot=$prefix/src
> > cygwin$  buildroot=$prefix/obj
> >
> >
> > First, I configure, build, and install binutils...
> >
> >
> > cygwin$  mkdir -p $buildroot/binutils
> > cygwin$  cd $buildroot/binutils
> > cygwin$  $srcroot/binutils-2.10.1/configure \
> >    --with-included-gettext \
> >    --host=$host --target=$target --build=$build \
> >    --prefix=$prefix -v
> > cygwin$  make >make.log 2>&1
> > cygwin$  make install >install.log 2>&1
> >
> >
> > Next, I configure, build, and install the GCC C compiler...
> >
> >
> > cygwin$  mkdir -p $buildroot/gcc
> > cygwin$  cd $buildroot/gcc
> > cygwin$  $srcroot/gcc-2.95.3-5/configure \
> >    --enable-languages=c,c++ \
> >    --with-included-gettext \
> >    --with-cpu=powerpc \
> >    --host=$host --target=$target --build=$build \
> >    --with-newlib \
> >    --prefix=$prefix -v
> > cygwin$  make LANGUAGES=c all-gcc >make_c_only.log 2>&1
> > cygwin$  make LANGUAGES=c install-gcc >install_c_only.log 2>&1
> >
> >
> > Next, I configure, build, and install newlib...
> >
> >
> > cygwin$  mkdir -p $buildroot/newlib
> > cygwin$  cd $buildroot/newlib
> > cygwin$  $srcroot/newlib-1.9.0/configure \
> >    --host=$host --target=$target --build=$build \
> >    --prefix=$prefix -v
> > cygwin$  make >make.log 2>&1
> > cygwin$  make install >install.log 2>&1
> >
> >
> > Next, I configure, build, and install the remaining GCC compilers, and
> > language runtime and/or support libraries...
> >
> >
> > cygwin$ cd $buildroot/gcc
> > cygwin$ make >make.log 2>&1
> > cygwin$ make install >install.log 2>&1
> >
> >
> > At this point, I I realize there are problems during compiles with a
> > linking stage.  After reading numerous FAQs, mailing list archives, etc, I
> > try to reconfigure, rebuild, and reinstall newlib with some additional
> > options...
> >
> >
> > cygwin$  cd $buildroot/newlib
> > cygwin$  mv make.log make.log.old
> > cygwin$  mv install.log install.log.old
> > cygwin$  make distclean
> > cygwin$  $srcroot/newlib-1.9.0/configure \
> >    --host=$host --target=$target --build=$build \
> >    --prefix=$prefix -v
> > cygwin$  make \
> >    CC_FOR_TARGET=$prefix/bin/$target-gcc \
> >    AS_FOR_TARGET=$prefix/bin/$target-as \
> >    LD_FOR_TARGET=$prefix/bin/$target-ld \
> >    AR_FOR_TARGET=$prefix/bin/$target-ar \
> >    RANLIB_FOR_TARGET=$prefix/bin/$target-ranlib \
> >    NM_FOR_TARGET=$prefix/bin/$target-nm \
> >    >make.log 2>&1
> > cygwin$  make install >install.log 2>&1
> >
> >
> > These are the problems I am experiencing...
> >
> >
> > cygwin$  $target-gcc helloworld.c
> > /usr/local/lib/gcc-lib/powerpc-unknown-eabi/2.95.3-5/../../../../powerpc-unknown-eabi/bin/ld:
> >
> > warning: cannot find entry symbol _start; defaulting to 01800074
> > /c/TEMP/ccWya32M.o: In function `main':
> > /c/TEMP/ccWya32M.o(.text+0x24): undefined reference to `printf'
> > /usr/local/lib/gcc-lib/powerpc-unknown-eabi/2.95.3-5/libgcc.a(eabi.o)
> > (.got2+0x8): undefined reference to `__SDATA_START__'
> > /usr/local/lib/gcc-lib/powerpc-unknown-eabi/2.95.3-5/libgcc.a(eabi.o)
> > (.got2+0xc): undefined reference to `__SBSS_END__'
> > /usr/local/lib/gcc-lib/powerpc-unknown-eabi/2.95.3-5/libgcc.a(eabi.o)
> > (.got2+0x14): undefined reference to `__SDATA2_START__'
> > /usr/local/lib/gcc-lib/powerpc-unknown-eabi/2.95.3-5/libgcc.a(eabi.o)
> > (.got2+0x18): undefined reference to `__SBSS2_END__'
> > /usr/local/lib/gcc-lib/powerpc-unknown-eabi/2.95.3-5/libgcc.a(eabi-ctors.o):
> >
> > In function `__do_global_ctors':
> > /usr/local/obj/gcc/gcc/eabi-ctors.c(.sdata+0x0): undefined reference to
> > `__init'
> > /usr/local/obj/gcc/gcc/eabi-ctors.c(.sdata+0x4): undefined reference to
> > `__fini'
> > collect2: ld returned 1 exit status
> >
> >
> > I believe that _start is supposed to be defined in crt0.o but I added -e
> > main to bypass this.  Does anyone know ehat eabi.o does or why eliminating
> > it reduces the errors?  Here is what I tried next...
> >
> >
> > cygwin$  $target-gcc -e main -mno-eabi helloworld.c
> > /c/TEMP/ccwCYRid.o: In function `main':
> > /c/TEMP/ccwCYRid.o(.text+0x20): undefined reference to `printf'
> > collect2: ld returned 1 exit status
> >
> >
> > Next I added the -L\usr\local\$target\lib command.  There are files called
> > libc.a and crt0.o in that directory.  This had no effect...
> >
> >
> > cygwin$  $target-gcc -e main -mno-eabi -L\usr\local\$target\lib
> > helloworld.c
> > /c/TEMP/ccFfHYTg.o: In function `main':
> > /c/TEMP/ccFfHYTg.o(.text+0x20): undefined reference to `printf'
> > collect2: ld returned 1 exit status
> >
> >
> > Finally I added the -lc to force libc.a to be linked.  Again, no effect...
> >
> >
> > cygwin$  $target-gcc -e main -mno-eabi -L\usr\local\$target\lib -lc
> > helloworld.c
> > /c/TEMP/ccTbWSZk.o: In function `main':
> > /c/TEMP/ccTbWSZk.o(.text+0x20): undefined reference to `printf'
> > collect2: ld returned 1 exit status
> >
> >
> > Any sugestions???  if I add the -msim option it compiles correctly for the
> > simulation board but in that case libc.a and crt0.o are not used.
> >
> > Regards,
> > Tony Ferranti
> > ferranti@us.ibm.com
> >
> >
> > ------
> > Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> > Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
> >
> 
> --
> Bill Gatliff
> bgat@billgatliff.com