Re: Undefined reference to strlen, although library is supplied

["Kai Ruottu" <karuottu at mbnet dot fi>]

On 9 Feb 2004 at 13:33, Hermann-Simon Lichte wrote:

> I am now trying to build a simple C++ application with my powerpc-eabi 
> compiler. I have written an appropriate linker configuration file that 
> fits my target development board (a Phytec phyCORE-MPC555 hooked up 
> using the Wiggler interface, just in case one likes to know).
> 
> The final link fails due to an undefined reference to strlen. However, 
> this function is present in libc.a, and even though I tell the linker to 
> use libc.a, it keeps complaining. An objdump reveals its presence, the 
> linker flags seem fine to me, so how come it doesn't link properly?
> 
> powerpc-eabi-gcc -T phycore555.ld -o build/blinky++.elf src/system.o 
> src/LED.o src/main.o -lstdc++ -lg -lc

 The '-verbose' option given to the GNU linker should give quite a
lot info about the linking phase. You can put it into your GCC
command line using the '-Wl,-verbose', meaning "Give the '-verbose'
option to the linker", please try the command:

  powerpc-eabi-gcc --help

for a short on-line 'manpage' for some important GCC options.

> /usr/local/lib/gcc-lib/powerpc-eabi/3.3.2/../../../../powerpc-eabi/bin/ld: 
> warning: cannot find entry symbol _start; defaulting to 00802000

 Probably your 'phycore555.ld' doesn't define any 'crt0.o', the
symbol '_start' is there.

> /usr/local/lib/gcc-lib/powerpc-eabi/3.3.2/libgcc.a(unwind-dw2.o)(.text+0x3e4): 
> In function `extract_cie_info':
> /home/gem/crossgcc/gcc-3.3.2/gcc/unwind-dw2.c:247: undefined reference 
> to `strlen'
> /usr/local/lib/gcc-lib/powerpc-eabi/3.3.2/libgcc.a(unwind-dw2.o)(.text+0xd08): 
> In function `execute_cfa_program':
> /home/gem/crossgcc/gcc-3.3.2/gcc/unwind-dw2.c:820: undefined reference 
> to `memcpy'

 The "-lstdc++ -lg -lc" means linking first against the
'libstdc++.a', then against the 'libg.a' - the 'debug' version of
the 'libc.a', then against the 'stripped from all the debug info',
normal 'libc.a'... So twice against 'libc.a'. What your linker
script defines as the libraries cannot be seen here, but when
the 'unwind-dw2()' should be there, linking against the 'libgcc,a'
happens at least once.

 But the usual link scheme is :  '-lgcc -lc -lgcc'  when the 'libc.a'
has everything belonging into a normal C library. The point is that
linking against the 'libgcc.a' is necessary before and after linking
the usual C libraries. The 'libgcc.a' may require functions from the
usual C libraries (as was the case here) and the usual C libraries
may require functions from the 'libgcc.a'.  If the '-lgcc' had been
before '-lc', the 'strlen()' and `memcpy' required by 'unwind-dw2()'
would have been solved...

 The basic property in the GNU ld is that it cannot go backwards
and search again the already handled libraries. So if any new
unresolved symbols will appear in the linked-in objects from the
handled libs, and they were defined in some earlier handled libs,
but the objects having them weren't linked in yet, these libs must
be scanned again...  With a glue library mixed into all this, it can
be that the link command for MIPS may have something like:

  -lgcc -lc -lpmon -lgcc -lc -lpmon -lgcc

where the 'libpmon.a' is a glue library for the PD PMON monitor
used on MIPS-based boards...

> I don't understand why the linker doesn't resolve the references.

 The link order has its meaning with the GNU ld as told...

> If I am not totally mislead, I believe that, in addition, I still need 
> to write startup code for my target. By leaving out -mads it is not 
> using any crt0, is it? What does actually need to be done in crt0?
> Is it sufficient to just set up the initial stack frame? To make
> global variables work, specific processor registers also need to be
> set up, as far as I know (I think they are R2, table of contents,
> and R13, global data, but I will do more research on that). What
> else needs to be included in a typical crt0 for an embedded target
> such as mine?

 The PowerPC EABI and SVR4/PPC docs, for instance in

   ftp://sources.redhat.com/pub/binutils/ppcdocs

(or something) could tell about the startup.  Also the generic SVR4
docs at:

    http://www.caldera.com/developer/devspecs

should tell about the 'process startup', when the (operating) system
exec()'s a program/executable there.... The generic ELF and DWARF
documentation and the PowerPC Supplement to SVR4 ABI should
describe all kind of things....

 But maybe the newlib provided 'crt0's, their sources, will be
the best examples about what to do there...

-------------------------------- clip ------------------------------
	.globl	_start
	.type	_start,@function
_start:
	bl	.Laddr			/* get current address */
.Laddr:
	mflr	r4			/* real address of .Laddr */
	lwz	r5,(.Lptr-.Laddr)(r4)	/* linker generated address of .LCTOC1 */
	add	r5,r5,r4		/* correct to real pointer */
	lwz	r4,.Ltable(r5)		/* get linker's idea of where .Laddr is */
	subf	r4,r4,r5		/* calculate difference between where linked and 
current */

	/* clear bss and sbss */
	lwz	r6,.Lbss_start(r5)	/* calculate beginning of the BSS */
	lwz	r7,.Lend(r5)		/* calculate end of the BSS */
	add	r6,r6,r4		/* adjust pointers */
	add	r7,r7,r4

	cmplw	1,r6,r7
	bc	4,4,.Ldone1

	subf	r8,r6,r7		/* number of bytes to zero */
	srwi	r9,r8,2			/* number of words to zero */
	mtctr	r9
	li	r0,0			/* zero to clear memory */
	addi	r6,r6,-4		/* adjust so we can use stwu */
.Lloop:
	stwu	r0,4(r6)		/* zero bss */
	bdnz	.Lloop
-------------------------------- clip ------------------------------

and so on...  The provided 'crt0.S' for boards should serve as the
base for your own startup.

Cheers, Kai


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