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]

Re: undefined references calling libc functions


mschmid@ascona.de wrote:
> 
> I setup a crosscompiler on intel platform using win2k for powerpc target.
>
> I wanted to test my CrossGcc with a simple hello program, but the linker
> failed resolving the libc library call to printf. It also failed with other libc
> calls. The libc.a is available within the directory i passed to gcc.
> 
> $ $target-gcc -e main -mno-eabi
> -I$src_root/BUILD/newlib/powerpc-eabi/newlib/usr/local/powerpc/powerpc-eabi/include
> -L$prefix/lib -lc -o hello hello.c
> cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp/cc5h1NDo.o: In function `main':
> cygdrive/c/DOKUME~1/ADMINI~1/LOKALE~1/Temp/cc5h1NDo.o(.text+0x20):
> undefined reference to `printf'
> collect2: ld returned 1 exit status
> 
> It seems that something failed creating the newlib for powerpc target, but
> in the log-files make.log and install.log i can't find any errors.

 Nothing probably failed...

> I took a closer look to the gcc manual, but i can't find any additional
> arguments i should pass to gcc.

 This thing has been handled many times on this list, but once more doesn't
hurt much...

 - in order to produce executables for something one needs a linker script
   (sometimes the built-in one in 'ld' is enough), a startup ('crt0.o' or
   something), the C-library (libc.a) and possibly a 'glue library' for the
   target system.

 - Sometimes the 'target' isn't fully defined, like the 'powerpc-eabi',
   'm68k-coff/elf', 'i386-elf' etc.  But targets like 'powerpc-linux-gnu'
   (Linux/PPC using glibc-2) and 'i386-sysv4.2' are fully defined.

 - For the 'fuzzy' targets something else must be known: the target board
   and the monitor/bootstrap-program on it, a simulator used instead of the
   target board, or something which can define the target system. For the
   some real targets there are glue libraries coming with newlib and these
   include the low-level, 'hardware-specific' routines for I/O and memory
   handling for the system.

 The 'real target' selection with powerpc-eabi is done with the '-m<zyz>'-
options for the by-newlib-supported systems:

----------------------------- clip -------------------------------------
-msim
  On embedded PowerPC systems, assume that the startup module is called
  sim-crt0.o and that the standard C libraries are libsim.a and libc.a.
  This is the default for powerpc-*-eabisim.  configurations.

-mmvme
  On embedded PowerPC systems, assume that the startup module is called
  crt0.o and the standard C libraries are libmvme.a and libc.a.

-mads
  On embedded PowerPC systems, assume that the startup module is called
  crt0.o and the standard C libraries are libads.a and libc.a.

-myellowknife
  On embedded PowerPC systems, assume that the startup module is called
  crt0.o and the standard C libraries are libyk.a and libc.a.
----------------------------- clip -------------------------------------

 If you looked at the GCC manual and the submodel options for RS6000/PowerPC,
these options should have been easily available.
 
> I think i don't need a startup file like crt0.o, because i build for a
> target without a system.

 Why you think so?  Shouldn't this be just on the contrary?  A 'system'
takes care of all the HW-initialization, setting system stack etc. while
in your case you need to take care of all this on a virgin system...

 My recommendation would be to use the '-msim', then if you build GDB for
'powerpc-eabi' target, you can run your the 'Hello World' there using the
'target sim' and see the message on the screen immediately, then single-step
your bigger programs on source and assembly level and do all kind of things
before you have any real HW... Then you can start to design your own linker
script and glue libraries for your own HW, the stuff in 'libgloss/ppc' can
serve as models...

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]