Greetings:

I successfully completed James Lynch's excellent tutorial using an
Olimex LPC2148 header board. I was able to flash a LED by executing the
gcc compiled examples loaded into either RAM or FLASH memory. However
when I try to expand the tutor example by adding calls to library
functions I find I get loader errors. It would appear the loader is able
to find the object code for the function called from the source code but
is unable to find the code for nested functions called from within the
library functions. An example is the following statement (which happens
to be on line 200 of my source code):

strcpy(UserIntLCD.line1,"QSG4 RF Signal Gen.");

This appears to compile without error but the loader gives the
following "undefined reference to `memcpy' error":

/cygdrive/t/eclipse/WorkSpace1/QSG4 LPC2148
Controller_rev0/QSG4main.c:200: undefined reference to `memcpy'

I presume 'memcpy' is called in a nested fashion by the 'strcpy'
library function. Coincidently the 'memcpy' function object code is
located in the same "libc.a" library archive file as 'strcpy'. I get
similar errors when I try to call other functions located in different
library archive files.

My loader is located on my drive 't' in the t:\gnuarm\bin' directory.
The command line contains '-L' path and '-lc' library source statements
is as follows:

arm-elf-ld -v -Map QSG4main.map -LT:/gnuarm/arm-elf/lib/fpu
-LT:/gnuarm/lib/gcc/arm-elf/4.1.1/fpu/ -lc -lgcc -lm -nostartfiles -T
QSG4_LD.cmd -o QSG4main.out crt.o QSG4main.o

I have confirmed the loader generates appropriate errors if I
change the -L path names or -l filenames thus I am certain the loader is
able to find the paths initially. I have tried adding environmental PATH
statements that point to the library archives. I get the same errors
running the loader from a cygwin command line as from Eclipse.

I have been struggling with this problem from time-to-time for a
couple of weeks now. As I have run out of ideas of what to try next I
sure would like some assistance if anyone here can help me.

Many thanks in advance!

--
Very Best Regards,
Tom Alldread

--
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 2006-08-03 Start a New Thread

T.M. (Tom) Alldread wrote:

> Greetings:
>
> I successfully completed James Lynch's excellent tutorial using an
> Olimex LPC2148 header board. I was able to flash a LED by executing the
> gcc compiled examples loaded into either RAM or FLASH memory. However
> when I try to expand the tutor example by adding calls to library
> functions I find I get loader errors. It would appear the loader is able
> to find the object code for the function called from the source code but
> is unable to find the code for nested functions called from within the
> library functions. An example is the following statement (which happens
> to be on line 200 of my source code):
>
> strcpy(UserIntLCD. line1,"QSG4 RF Signal Gen.");
>
> This appears to compile without error but the loader gives the
> following "undefined reference to `memcpy' error":
>
> /cygdrive/t/ eclipse/WorkSpac e1/QSG4 LPC2148
> Controller_rev0/ QSG4main. c:200: undefined reference to `memcpy'
>
> I presume 'memcpy' is called in a nested fashion by the 'strcpy'
> library function. Coincidently the 'memcpy' function object code is
> located in the same "libc.a" library archive file as 'strcpy'. I get
> similar errors when I try to call other functions located in different
> library archive files.
>
> My loader is located on my drive 't' in the t:\gnuarm\bin' directory.
> The command line contains '-L' path and '-lc' library source statements
> is as follows:
>
> arm-elf-ld -v -Map QSG4main.map -LT:/gnuarm/ arm-elf/lib/ fpu
> -LT:/gnuarm/ lib/gcc/arm- elf/4.1.1/ fpu/ -lc -lgcc -lm -nostartfiles -T
> QSG4_LD.cmd -o QSG4main.out crt.o QSG4main.o
>
> I have confirmed the loader generates appropriate errors if I
> change the -L path names or -l filenames thus I am certain the loader is
> able to find the paths initially. I have tried adding environmental PATH
> statements that point to the library archives. I get the same errors
> running the loader from a cygwin command line as from Eclipse.
>
> I have been struggling with this problem from time-to-time for a
> couple of weeks now. As I have run out of ideas of what to try next I
> sure would like some assistance if anyone here can help me.
>
It is because 'ld' (the linker) does not do circular resolution of
symbols. When you put the lib first in the link list (e.g. -lc
QSG4main.out crt.o QSG4main.o), it won't find the reference to memcpy.
Put the libs at the end of the list, "QSG4main.out crt.o QSG4main.o -lc"
or place "INPUT (-lc);" at the very end of your *.ld script (outside the
SECTIONS definitions).

When ld looks for resolution of a symbol name, it look forwards (in the
subsequently named objects / libs). The logic seems backwards as many
DOS linkers will either do circular resolutions or they do backward
reference.

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread

Greetings Tom, WN3L

Many thanks for your response! Whew! - I think I would have been
struggling with this for a much longer time without your help. After
picking a different library archive I am finally able to compile. I
encountered the need for a non-FPU library I presume because the LPC has
a hardware multiplier which is another subject for me to look into.
Thanks Again!
Tom, VA7TA

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.9/417 - Release Date: 2006-08-11 Start a New Thread

Hello,

I use the same setup and have similar problem, that the file does get
compiled, but the linking shows the list of error message

smtp.c:108: undefined reference to `strcpy'

The string.h file is in the C:/GCCFD/Gnuarm/arm-elf/include directory.
I tried several ways to add this in the linker command, but the error
message remains meaning it did not look at the correct folder.
How do I add this path correctly in the makefile for the linker
command? Any examples?
Thank you ..richard

--- In l..., Tom Walsh wrote:
>
> T.M. (Tom) Alldread wrote:
> > Greetings:
> >
> > I successfully completed James Lynch's excellent tutorial using an
> > Olimex LPC2148 header board. I was able to flash a LED by
executing the
> > gcc compiled examples loaded into either RAM or FLASH memory. However
> > when I try to expand the tutor example by adding calls to library
> > functions I find I get loader errors. It would appear the loader
is able
> > to find the object code for the function called from the source
code but
> > is unable to find the code for nested functions called from within the
> > library functions. An example is the following statement (which
happens
> > to be on line 200 of my source code):
> >
> > strcpy(UserIntLCD. line1,"QSG4 RF Signal Gen.");
> >
> > This appears to compile without error but the loader gives the
> > following "undefined reference to `memcpy' error":
> >
> > /cygdrive/t/ eclipse/WorkSpac e1/QSG4 LPC2148
> > Controller_rev0/ QSG4main. c:200: undefined reference to `memcpy'
> >
> > I presume 'memcpy' is called in a nested fashion by the 'strcpy'
> > library function. Coincidently the 'memcpy' function object code is
> > located in the same "libc.a" library archive file as 'strcpy'. I get
> > similar errors when I try to call other functions located in different
> > library archive files.
> >
> > My loader is located on my drive 't' in the t:\gnuarm\bin' directory.
> > The command line contains '-L' path and '-lc' library source
statements
> > is as follows:
> >
> > arm-elf-ld -v -Map QSG4main.map -LT:/gnuarm/ arm-elf/lib/ fpu
> > -LT:/gnuarm/ lib/gcc/arm- elf/4.1.1/ fpu/ -lc -lgcc -lm
-nostartfiles -T
> > QSG4_LD.cmd -o QSG4main.out crt.o QSG4main.o
> >
> > I have confirmed the loader generates appropriate errors if I
> > change the -L path names or -l filenames thus I am certain the
loader is
> > able to find the paths initially. I have tried adding
environmental PATH
> > statements that point to the library archives. I get the same errors
> > running the loader from a cygwin command line as from Eclipse.
> >
> > I have been struggling with this problem from time-to-time for a
> > couple of weeks now. As I have run out of ideas of what to try next I
> > sure would like some assistance if anyone here can help me.
> >
> It is because 'ld' (the linker) does not do circular resolution of
> symbols. When you put the lib first in the link list (e.g. -lc
> QSG4main.out crt.o QSG4main.o), it won't find the reference to memcpy.
> Put the libs at the end of the list, "QSG4main.out crt.o QSG4main.o
-lc"
> or place "INPUT (-lc);" at the very end of your *.ld script (outside
the
> SECTIONS definitions).
>
> When ld looks for resolution of a symbol name, it look forwards (in the
> subsequently named objects / libs). The logic seems backwards as many
> DOS linkers will either do circular resolutions or they do backward
> reference.
>
> TomW
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------
> Start a New Thread

The problem is not with finding string.h. The linker does not use
.h files, only the compiler does. This error is stating that
in the final link, the routine strcpy could not be found. Likely there
is a library that you needed to include in the link. Make sure you have
-lc and -lgcc at the end of your link command line as one of these libraries
probably contains strcpy (likely libc).

Mike
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of R. Wimmer
> Sent: Monday, August 14, 2006 11:16 AM
> To: l...
> Subject: [lpc2000] Re: Linking Problem -Eclipse,cygwin,gnuarm,gcc
> Hello,
>
> I use the same setup and have similar problem, that the file does get
> compiled, but the linking shows the list of error message
>
> smtp.c:108: undefined reference to `strcpy'
>
> The string.h file is in the C:/GCCFD/Gnuarm/arm-elf/include directory.
> I tried several ways to add this in the linker command, but the error
> message remains meaning it did not look at the correct folder.
> How do I add this path correctly in the makefile for the linker
> command? Any examples?
> Thank you ..richard
>
> --- In l..., Tom Walsh wrote:
> >
> > T.M. (Tom) Alldread wrote:
> > > Greetings:
> > >
> > > I successfully completed James Lynch's excellent tutorial using an
> > > Olimex LPC2148 header board. I was able to flash a LED by
> executing the
> > > gcc compiled examples loaded into either RAM or FLASH
> memory. However
> > > when I try to expand the tutor example by adding calls to library
> > > functions I find I get loader errors. It would appear the loader
> is able
> > > to find the object code for the function called from the source
> code but
> > > is unable to find the code for nested functions called
> from within the
> > > library functions. An example is the following statement (which
> happens
> > > to be on line 200 of my source code):
> > >
> > > strcpy(UserIntLCD. line1,"QSG4 RF Signal Gen.");
> > >
> > > This appears to compile without error but the loader gives the
> > > following "undefined reference to `memcpy' error":
> > >
> > > /cygdrive/t/ eclipse/WorkSpac e1/QSG4 LPC2148
> > > Controller_rev0/ QSG4main. c:200: undefined reference to `memcpy'
> > >
> > > I presume 'memcpy' is called in a nested fashion by the 'strcpy'
> > > library function. Coincidently the 'memcpy' function
> object code is
> > > located in the same "libc.a" library archive file as
> 'strcpy'. I get
> > > similar errors when I try to call other functions located
> in different
> > > library archive files.
> > >
> > > My loader is located on my drive 't' in the
> t:\gnuarm\bin' directory.
> > > The command line contains '-L' path and '-lc' library source
> statements
> > > is as follows:
> > >
> > > arm-elf-ld -v -Map QSG4main.map -LT:/gnuarm/ arm-elf/lib/ fpu
> > > -LT:/gnuarm/ lib/gcc/arm- elf/4.1.1/ fpu/ -lc -lgcc -lm
> -nostartfiles -T
> > > QSG4_LD.cmd -o QSG4main.out crt.o QSG4main.o
> > >
> > > I have confirmed the loader generates appropriate errors if I
> > > change the -L path names or -l filenames thus I am certain the
> loader is
> > > able to find the paths initially. I have tried adding
> environmental PATH
> > > statements that point to the library archives. I get the
> same errors
> > > running the loader from a cygwin command line as from Eclipse.
> > >
> > > I have been struggling with this problem from time-to-time for a
> > > couple of weeks now. As I have run out of ideas of what
> to try next I
> > > sure would like some assistance if anyone here can help me.
> > >
> > It is because 'ld' (the linker) does not do circular resolution of
> > symbols. When you put the lib first in the link list (e.g. -lc
> > QSG4main.out crt.o QSG4main.o), it won't find the reference
> to memcpy.
> > Put the libs at the end of the list, "QSG4main.out crt.o QSG4main.o
> -lc"
> > or place "INPUT (-lc);" at the very end of your *.ld script (outside
> the
> > SECTIONS definitions).
> >
> > When ld looks for resolution of a symbol name, it look
> forwards (in the
> > subsequently named objects / libs). The logic seems
> backwards as many
> > DOS linkers will either do circular resolutions or they do backward
> > reference.
> >
> > TomW
> >
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware.net, http://cyberiansoftware.com
> > "Windows? No thanks, I have work to do..."
> > ----------------
> > Start a New Thread

On 8/14/06, Michael Anton wrote:
> The problem is not with finding string.h. The linker does not use
> .h files, only the compiler does. This error is stating that
> in the final link, the routine strcpy could not be found. Likely there
> is a library that you needed to include in the link. Make sure you have
> -lc and -lgcc at the end of your link command line as one of these libraries
> probably contains strcpy (likely libc).

As a general rule, you shouldn't call ld to perform the linker step,
but rather call gcc.

gcc will often add extra libraries (like -lc and -gcc) which may be
required for your machine.

To see what libraries gcc would add, try executing the following:

touch empty.c
arm-elf-gcc -v empty.c

This will print out the full command line passed to the compiler,
assembler, and linker (the linker might be called ld or it may be
called collect2).

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/ Start a New Thread

Dave Hylands wrote:

> On 8/14/06, Michael Anton > > wrote:
> > The problem is not with finding string.h. The linker does not use
> > .h files, only the compiler does. This error is stating that
> > in the final link, the routine strcpy could not be found. Likely there
> > is a library that you needed to include in the link. Make sure you have
> > -lc and -lgcc at the end of your link command line as one of these
> libraries
> > probably contains strcpy (likely libc).
>
> As a general rule, you shouldn't call ld to perform the linker step,
> but rather call gcc.
>
> gcc will often add extra libraries (like -lc and -gcc) which may be
> required for your machine.
>
> To see what libraries gcc would add, try executing the following:
>
> touch empty.c
> arm-elf-gcc -v empty.c
>
> This will print out the full command line passed to the compiler,
> assembler, and linker (the linker might be called ld or it may be
> called collect2).
>
LOL, it most certainly will give you a little more information. heh.
Yes, when all else fails, I have had to resort to making the process
verbose, then track it down.

Regards,

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
www.openhardware.net www.cyberiansoftware.com www.openzipit.org
"Windows? No thanks, I have work to do..."
---------------- Start a New Thread