0

I'm using GCC (CygWin) cross-compiling targeting an Arm7 processor. the problem is none of the standard library functions are available for my program. as I understand it, libc.a is the library i should be using. strangely, this file has been copied to the application source directory.

I would've thought if I did the following, I should be able to use these functions:

  1. have included (enclosed in <>) string.h and stdlib.h in my LCD.c file
  2. mention libc.a to the linker

During make, here's what it says:

$ make
.compiling
..linking
arm-elf-ld -v -Map main.map -nostartfiles -T simple.cmd -o main.out start.o ivt.
o main.o libc.a LCD.o
GNU ld version 2.14 20030612
LCD.o(.text+0x75c): In function `LCD_DispSmallDigits':
: undefined reference to `strlen'
LCD.o(.text+0x22d4): In function `LCD_DispSelMsgAt':
: undefined reference to `malloc'
LCD.o(.text+0x22e0): In function `LCD_DispSelMsgAt':
: undefined reference to `strcpy'
LCD.o(.text+0x2308): In function `LCD_DispSelMsgAt':
: undefined reference to `free'
LCD.o(.text+0x2358): In function `LCD_DispNumMsgAt':
: undefined reference to `malloc'
LCD.o(.text+0x2368): In function `LCD_DispNumMsgAt':
: undefined reference to `sprintf'
LCD.o(.text+0x2384): In function `LCD_DispNumMsgAt':
: undefined reference to `free'

the code I'm using is quite mundane:

void LCD_DispSelMsgAt(int iRow, int iCol, int bSelected, char* s)
{
    int i;
    char* sBuffer = (char*) malloc(100);

    strcpy(sBuffer, s);

    if (bSelected)
        for (i=0; i<strlen(sBuffer); i++)
        if ((*(sBuffer + i)>='a') && (*(sBuffer + i)<='z'))
            *(sBuffer + i) = (*(sBuffer + i)) - 0x20;

    LCD_DispMsgAt(iRow, iCol, sBuffer);

    free(sBuffer);
}

how can I get access to those standard routines?

thank you!

PS: it seems to me I'm having quite a "general" problem so what I'm about to say is not central to this question but i'll mention it anyway...

I noticed something that specifically relates to strlen( ). the prototype for strlen( ) has the parameter as "const char* s". it seems then it works fine with:

i = strlen("abc")

but not in the code sample routine shown above. that wouldn't be a very helpful library routine that can't be used as strlen(char* s).

reply to @n.m.:

adding /gnude/arm-elf/lib/libc.a to the linker command line introduced a "thousand" errors.

$ make
..linking
arm-elf-ld -v -Map main.map -nostartfiles -T LinkerScript.cmd -L /gnude/arm-elf/
lib -o main.out start.o ivt.o main.o LCD.o /gnude/arm-elf/lib/libc.a
GNU ld version 2.14 20030612
/gnude/arm-elf/lib/libc.a(syscalls.o)(.text+0x714): In function `_sbrk':
: undefined reference to `end'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x8c0): In function `_vfprintf_r':
: undefined reference to `__eqdf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1054): In function `_vfprintf_r':
: undefined reference to `__nedf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x155c): In function `_vfprintf_r':
: undefined reference to `__umoddi3'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1578): In function `_vfprintf_r':
: undefined reference to `__udivdi3'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1834): In function `_vfprintf_r':
: undefined reference to `__ltdf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1d98): In function `cvt':
: undefined reference to `__eqdf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1e10): In function `cvt':
: undefined reference to `__nedf2'
/gnude/arm-elf/lib/libc.a(vfprintf.o)(.text+0x1e30): In function `cvt':
: undefined reference to `__negdf2'
/gnude/arm-elf/lib/libc.a(dtoa.o)(.text+0x7c): In function `_dtoa_r':
: undefined reference to `__eqdf2'

not sure what i should do next. i think i'll start by removing the explicit libc.a from the linker command line.

X-Ray
  • 2,816
  • 1
  • 37
  • 66
  • Your linker doesn't find your arm libraries, you need to tell it where they are (-L /path/to/folder/with/arm/libs). `const` is not a problem, you just need to learn how it works. – n. m. could be an AI Apr 03 '13 at 05:49
  • 2
    Is your libc.a at correct position? (see http://stackoverflow.com/questions/45135/linker-order-gcc) – dbrank0 Apr 03 '13 at 06:49
  • @n.m., thank you for your reply. I removed the libc.a file from the project directory and added -L /gnude/arm-elf/lib. now it says it can't find libc.a. makes me wonder if libc.a should be mentioned differently in the linker command line so it knows it's a library file. – X-Ray Apr 03 '13 at 15:33
  • @dbrank0, thank you for your reply; i'll look into this in the evening. I did try putting it earlier in the list but my attempt was not very "enlightened". – X-Ray Apr 03 '13 at 15:34
  • 1
    Oh I see you are referencing libc.a directly. This is not needed, the linker searches the standard library by default. It only needs to know the directory if it's not one of the standard places. – n. m. could be an AI Apr 03 '13 at 17:17
  • I didn't know that was not required...removed libc.a from the linker command line. Still getting the same errors as before, though (undefined function reference). We're getting "closer"! Surely I've forgotten something simple or did something dumb... thank you for your help with this! – X-Ray Apr 03 '13 at 17:30
  • OK so you may temporarily add libc.a back but with a full path, like /gnude/arm-elf/lib/libc.a, after all of the objects and other libs on the command line. If you still get undefined symbols, your libc.a is probably for a wrong architecture. – n. m. could be an AI Apr 03 '13 at 19:28
  • added reply to question so we can use the code formatting. – X-Ray Apr 03 '13 at 19:53
  • I think i know what I should do now. I ran FileMon (SysInternals) to see what files it's looking for & what's happening. INTERESTING: as currently configured, it never looks for libc.a during the Make process! Something else i see is that it was looking at CodeSourcery & CodeSourcery Lite so i removed them from the system "path" env. variable. now it doesn't look at CodeSourcery* anymore but still *never* looks for libc.a. I suppose there must be some way to say we want to use a given library but I don't (yet) know how. Any ideas? – X-Ray Apr 03 '13 at 20:38
  • i see the linker needs the "-lc" command line parameter to know it should be using libc.a. *still* doesn't work. uninstalling all related software, only installing used tools. – X-Ray Apr 05 '13 at 14:04

0 Answers0