Re: linking problem - cannot find libraries even though searchpat h se ems OK!

[Kai Ruottu <kai dot ruottu at luukku dot com>]

"Larsen, Morten ActeNO" wrote:
> 
> > /usr/local/bin/arm-elf-ld -L/usr/local/arm-elf/lib -Ttext 0x2018000 -e
> 0x2018000 -g -v  -o ANGEL_OBJ
> > /pio_test.bin  ANGEL_OBJ/in_main.o ANGEL_OBJ/asm_path.o32
> ANGEL_OBJ/in_eb40.o32 ANGEL_OBJ/in_reset.o
> > 32  ANGEL_OBJ/pio_test.o  -llib32 -langel -llibc -llibgcc
> > GNU ld version 2.10 (with BFD 2.10)
> > /usr/local/bin/arm-elf-ld: cannot find -llib32

 Here seems to be weird things, for a 'lib32.a' using a '-l32' on the 'ld'
command is the rule. I don't expect the library name being 'liblib32.a'...
But the format used for the 'libangel.a' is right.

 With DOS-hosted tools I have seen the 'lib'-prefix in the names being
redundant, the '.a' type tells the fact good enough... A simple patch to
the GNU ld enables it to search the libs with their base names like 'c.a',
'm.a', 'gcc.a',.... And normally this gets the names like 'libkernel32.a'
to fit back into the '8 + 3' rule ('kernel32.a')...

 So normally the 'lib' prefix in the libnames must be stripped away when
writing those '-l<name>' options.

> But, I previously used a distribution made by Andy Hare (see:
> http://www.ahare.btinternet.co.uk/) -
> w. boardsupport for the Atmel AT91EB01 evaluation board. This distribution
> also contains the
> prebuilt Atmel AT91 peripheral support library. This worked just fine with
> the RDI serial debug protocol
> (and Angel monitor on the target (AT91EB01/40) board!:-)
> 
> But, now I have moved on to the AT91EB40 board, and want to use JTAG
> debugging (Macgraigor "Wiggler" dongle) -
> so I downloaded this distribution since there was support for this device in
> there, and installed it.
> I added the .lib/.a files (ver. 2.95.2 for the GNU libs, ver. 2.1 for the
> AT91 libs) afterwards.
> Maybe not 'the right way' to do things - but can this really topple the
> whole thing???

 On the contrary my opinion is that this is just the right thing to do...
I would wish that the GCC-builders didn't always start from scratch, but
would first install a prebuilt toolchain, then use the libs and headers
from it when building their own GCC...

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