I’m having a major headache with adding an include directory path in
Eclipse. I use Project/Properties/C/C++ General/Paths and Symbols to add
the path. It shows up in the project’s Includes section, but when I
build it still reports “No such file or directory”! What? Why?
Here’s a pic that’s worth 1000 more words. I know, my E and RS defs are wrong. Just spotted that. 
I checked the settings for my (non-ARM) Eclipse GCC toolchain and it looks like you inserted the path correctly. Try clicking on the root of the C/C++ Project and press F5 (refresh). Then click on your C source file and do a clean (Project | Clean).
Thanks Riden, but I've done those things many times before and it does nothing. I'm starting to think there's something wrong with XP. I added the path to the path environment variable manually and rebooted. Still can't find the files in that dir without a full path. That seems very strange to me.riden:
I checked the settings for my (non-ARM) Eclipse GCC toolchain and it looks like you inserted the path correctly. Try clicking on the root of the C/C++ Project and press F5 (refresh). Then click on your C source file and do a clean (Project | Clean).
futz:
I’m starting to think there’s something wrong with XP. I added the path to the path environment variable manually and rebooted. Still can’t find the files in that dir without a full path. That seems very strange to me.
I’m pretty sure that XP isn’t the problem, or at least this problem. 
When you added the include paths, did you leave “Is a workspace path” unchecked? The other thing I would check is the setting of the auto-discover paths, it should be checked. I’m sorry, but I’m on the way out the door and can’t give you the exact path.
I think you're right. The path enviro variable is just for executables, isn't it?riden:
I’m pretty sure that XP isn’t the problem, or at least this problem.
Yes. What does that mean, by the way (if you have time)?When you added the include paths, did you leave “Is a workspace path” unchecked?
Like this?The other thing I would check is the setting of the auto-discover paths, it should be checked.
To answer your questions:
Yes, the environment path is important when the project is built. It is the way that the tools know where the required files are located. The problem that you are seeing is that the Eclipse IDE can’t resolve the location of one of the system include files, which makes it an issue with the project settings. The project may or may not build when make is run. When I ran into a similar situation with a different toolset, the IDE was off, but when I executed make, it was able to build the project.
If “Is a workspace path” is checked, it tells Eclipse to reference the path relative to the project’s workspace path (I believe) rather than an absolute path. A similar setting in the Java perspective would give me fits from time to time when I wanted to reference files outside of the workspace.
Yes, the “Automate discovery of paths…” was the setting I was thinking about.
Did you install the Zylin plug-in for Eclipse? I was going to play around with it tonight, but my current working Eclipse is configured for generating x86 code and uses Cygwin. I’m hesitant to tinker with my installation and I would have to clone my VM.
Ah! OK! That makes sense. Why the hell didn't they say so? :mrgreen: Everybody wants to make up their own names for things (microsoft) instead of calling them what they are. It's annoying.riden:
2) If “Is a workspace path” is checked, it tells Eclipse to reference the path relative to the project’s workspace path (I believe) rather than an absolute path.
That was enabled all along. I've tried every option in there and nothing helps. It doesn't help that I'm completely lost about what they all mean. :mrgreen:
- Yes, the “Automate discovery of paths…” was the setting I was thinking about.
I installed this whole thing from the Olimex disk that came with my [[LPC-P2148](http://www.optimal-microsystems.com/store/product_info.php?cPath=24&products_id=114&osCsid=32e20479eb85656ea0232f3025b7e3dc) board. Zylin was part of it. The entire thing was broken and unuseable when installed (thanks a lot Olimex :roll: ). I've fiddled with it for days and have it almost working now.Did you install the Zylin plug-in for Eclipse? I was going to play around with it tonight, but my current working Eclipse is configured for generating x86 code and uses Cygwin. I’m hesitant to tinker with my installation and I would have to clone my VM.
I now have it compiling properly and the debugger almost working. It still won’t flash the chip, and I don’t know how to compile in debug mode yet (this is a major part of why the debugger doesn’t work :mrgreen:). I’m using Flash Magic to flash for now, and have no debugger.
If I can get this thing to work I’ll have learned something and saved $150. But too much more of this foolishness and I’m going to give Rowley their $150 and use Crossworks. I used the demo for 30 days. Crossworks is SO nice and easy! Everything works “out of the box”. The debugger is really nice.](http://www.optimal-microsystems.com/store/product_info.php?cPath=24&products_id=114&osCsid=32e20479eb85656ea0232f3025b7e3dc)
futz:
I installed this whole thing from the Olimex disk that came with my [LPC-P2148 board. Zylin was part of it. The entire thing was broken and unuseable when installed (thanks a lot Olimex :roll: ). I’ve fiddled with it for days and have it almost working now.[/quote]I can totally relate to your situation. When I went to modify the Olimex’s PIC-WEB code to add some features, the project wouldn’t build because of files that weren’t included in the project. When I did get it to build, the image file it created was larger than 64k and the PIC-WEB firmware couldn’t handle the image file. I found and fixed the bug in the code and was good to go until a new round of problems showed up in the 4.x stack. Got those fixed and now everything is fine. Clearly the firmware that was shipped with the PIC-WEB wasn’t built from the source provided. Our QA group always installs and tests applications on clean machines (or VM’s) to avoid problems like the ones that you and I have encountered.I have to admit that I wouldn’t have had the opportunity to learn so much about the PIC-WEB firmware if the code actually built out of the box, but it took a lot of my limited time, time that I would have preferred to invest in my projects. I was able to leverage my development experience to fix the issues, but pity the person just starting out. Their frustration would be much greater than mine.
It sounds like you’re nearly there, and I wish you luck getting things working as desired. And you have a fallback (Crossworks) if things don’t pan out.](http://www.optimal-microsystems.com/store/product_info.php?cPath=24&products_id=114&osCsid=32e20479eb85656ea0232f3025b7e3dc)
Ok, I just checked and found that I've been compiling with the -g debug info option all along, so that aint it. :)futz:
and I don’t know how to compile in debug mode yet
Debugger looks like it might work if I could figure out how to get it to flash the chip. It appears that and the include path problem are all I need to get fixed now. I'm Google-exhausted from looking at tons of searches and trying things. Nothing works...and have no debugger.
I’m using Eclipse/yagarto/zylin with Olimex ARM-USB-TINY and an Olimex LPC-P2148 target board.
OK, after days of confusion and Googling, 99.999% of which was useless, I finally figured that out.futz:
I’m having a major headache with adding an include directory path inEclipse. I use Project/Properties/C/C++ General/Paths and Symbols to add
the path. It shows up in the project’s Includes section, but when I
build it still reports “No such file or directory”! What? Why?
Manually putting paths in Eclipse’s Project/Properties/C/C++ General/Paths and Symbols is futile. It doesn’t work that way. The proper way to do it is to put the path in the -I compiler flag in your makefile as follows:
CFLAGS = -Ic:/gccfd/yagarto/arm-elf/include -c -fno-common -O0 -g
Then it shows up in the project view (and in the Project/Properties/C/C++ General/Paths and Symbols dialog box too) and actually gets found. I assume this is where automated discovery comes in, but I don’t know how it all works.
Now that I got that cured, I immediately have another problem. I build and get this error
make all
arm-elf-gcc -Ic:/gccfd/yagarto/arm-elf/include -c -fno-common -O0 -g lcd4bit_busy.c
arm-elf-ld -v -Map lcd4bit_busy.map -T2138_demo.cmd -o lcd4bit_busy.out crt.o lcd4bit_busy.o
GNU ld version 2.17
lcd4bit_busy.o: In function `main':
C:\gccfd\projects\lcd4bit/lcd4bit_busy.c:22: undefined reference to `sprintf'
make: *** [lcd4bit_busy.out] Error 1
Should I be looking for another option that tells it where something else is?
add -L"your path to the lib folder" -lc
-Lpath = sets the path for libraries
-lxxx = link with library xxx. The C library (where sprintf is) is just called c, so that’s why -lc
Ah, then I was on the right track. I had been playing with those two (and getting nowhere), but I see nothing in any of the lib dirs called "c", or "c.a". There is a "libc.a",inventore123:
add -L"your path to the lib folder" -lc-Lpath = sets the path for libraries
-lxxx = link with library xxx. The C library (where sprintf is) is just called c, so that’s why -lc
http://ghmicro.com/images/stories/LPC20 … lf_lib.jpg
I tried
LFLAGS = -Map rtc_clock.map -T2138_demo.cmd -Lc:/gccfd/yagarto/arm-elf/lib -lc
and got this
rtc_clock.o: In function `main':
C:\gccfd\projects\rtc_clock/rtc_clock.c:21: undefined reference to `sprintf'
make: *** [rtc_clock.out] Error 1
Tried every other variation I could think of, including -llibc and -llibc.a and many others, and nothing seems to work. There’s another lib dir there too. It looks like the screen grab below. Tried that one as well. No go.
I found [this thread at [Mikrocontroller.net Forum. Dmitry is having the exact same problem as I am. Here’s the message I’m looking at:
Clifford suggests invoking the linker indirectly through the compiler front end. How is that done?Dmitry Timas wrote:
Linking…
arm-elf-ld -v -Map main.map -Tlpc2378.ld -o main.out main.o
GNU ld (GNU Binutils) 2.18
main.o: In function `main’:
test06/main.c:9: undefined reference to `strcpy’
make: *** [main.out] Error 1
Here your linker command line shows that you have not linked any
libraries.
If you call the linker directly, you have to specify the standard
libraries and their paths. To add to the complexity, there are multiple
versions of the standard library depending on the target for Thumb, ARM,
Interwork, FPA support etc.
I believe that the simplest solution is to invoke the linker indirectly
through the compiler front end (arm-elf-gcc or arm-elf-g++). This
implicitly determines the correct libraries from the compiler options.
Otherwise you need some appropriate -L arguments, and at least -lc
and -lgcc (in that order), and possibly -lm ahead of those if using the
math library.
Clifford
After reading that post (and a few others) and trying some things, my makefile looks like this.
NAME = lcd4bit
CC = arm-elf-gcc
LD = arm-elf-ld -v
AR = arm-elf-ar
AS = arm-elf-as
CP = arm-elf-objcopy
OD = arm-elf-objdump
CFLAGS = -Ic:/gccfd/yagarto/arm-elf/include -Ic:/gccfd/yagarto/include -c -fno-common -O0 -g
AFLAGS = -ahls -mapcs-32 -o crt.o
LFLAGS = -Map rtc_clock.map -T2138_demo.cmd -Lc:/gccfd/yagarto/lib/gcc/arm-elf/4.2.1/interwork -Lc:/gccfd/yagarto/arm-elf/lib/interwork -nostdlibs --start-group
CPFLAGS = -O binary
HEXFLAGS = -O ihex
ODFLAGS = -x --syms
all: test
clean:
-rm crt.lst crt.o rtc_clock.o rtc_clock.out rtc_clock.map rtc_clock.dmp rtc_clock.bin
test: rtc_clock.out
$(CP) $(CPFLAGS) rtc_clock.out rtc_clock.bin
$(OD) $(ODFLAGS) rtc_clock.out > rtc_clock.dmp
$(CP) $(HEXFLAGS) rtc_clock.out rtc_clock.hex
rtc_clock.out: crt.o rtc_clock.o 2138_demo.cmd
$(LD) $(LFLAGS) -o rtc_clock.out crt.o rtc_clock.o
crt.o: crt.s
$(AS) $(AFLAGS) crt.s > crt.lst
rtc_clock.o: rtc_clock.c
$(CC) $(CFLAGS) rtc_clock.c
It still doesn’t work. I get this output when I make:
**** Build of configuration Default for project rtc_clock ****
make all
arm-elf-ld -v -Map rtc_clock.map -T2138_demo.cmd -Lc:/gccfd/yagarto/lib/gcc/arm-elf/4.2.1/interwork -Lc:/gccfd/yagarto/arm-elf/lib/interwork -nostdlibs --start-group -o rtc_clock.out crt.o rtc_clock.o
GNU ld version 2.17
rtc_clock.o: In function `main':
C:\gccfd\projects\rtc_clock/rtc_clock.c:21: undefined reference to `sprintf'
make: *** [rtc_clock.out] Error 1
](http://en.mikrocontroller.net/)](Topics in all forums - EmbDev.net)
All library files do begin with “lib” and end with “.a”. When you specify “-lc” gcc will add “lib” and “.a” to the name forming the correct filename “libc.a”
If the include path worked with “-Ic:/gccfd/yagarto/arm-elf/include”
your linker path should be “-Lc:/gccfd/yagarto/arm-elf/lib -lc”
anyway, yes, you should call the linker through gcc
LFLAGS= -mcpu=arm7tdmi -Wl,-Map,rtc_clock.map -T2138_demo.cmd -nostdlib
LINK_LIBS= -Lc:/gccfd/yagarto/arm-elf/lib -lc
and your link rule should be
rtc_clock.out: crt.o rtc_clock.o 2138_demo.cmd
$(CC) $(LFLAGS) -o rtc_clock.out crt.o rtc_clock.o $(LINK_LIBS)
Ya, I had surmised that by the end of last evening's entertainment. Thank you.inventore123:
All library files do begin with “lib” and end with “.a”. When you specify “-lc” gcc will add “lib” and “.a” to the name forming the correct filename “libc.a”
I'll try all that out tonight. I can't believe I couldn't find a working makefile on the web. Will let you know how it goes. Thanks again for the assistance. :DIf the include path worked with “-Ic:/gccfd/yagarto/arm-elf/include”
your linker path should be “-Lc:/gccfd/yagarto/arm-elf/lib -lc”
anyway, yes, you should call the linker through gcc
LFLAGS= -mcpu=arm7tdmi -Wl,-Map,rtc_clock.map -T2138_demo.cmd -nostdlib
LINK_LIBS= -Lc:/gccfd/yagarto/arm-elf/lib -lc
and your link rule should be
rtc_clock.out: crt.o rtc_clock.o 2138_demo.cmd
$(CC) $(LFLAGS) -o rtc_clock.out crt.o rtc_clock.o $(LINK_LIBS)
Tried that. No go. Here's the makefile at present:inventore123:
If the include path worked with “-Ic:/gccfd/yagarto/arm-elf/include”your linker path should be “-Lc:/gccfd/yagarto/arm-elf/lib -lc”
anyway, yes, you should call the linker through gcc
LFLAGS= -mcpu=arm7tdmi -Wl,-Map,rtc_clock.map -T2138_demo.cmd -nostdlib
LINK_LIBS= -Lc:/gccfd/yagarto/arm-elf/lib -lc
and your link rule should be
rtc_clock.out: crt.o rtc_clock.o 2138_demo.cmd
$(CC) $(LFLAGS) -o rtc_clock.out crt.o rtc_clock.o $(LINK_LIBS)
NAME = lcd4bit
CC = arm-elf-gcc
LD = arm-elf-ld -v
AR = arm-elf-ar
AS = arm-elf-as
CP = arm-elf-objcopy
OD = arm-elf-objdump
CFLAGS = -Ic:/gccfd/yagarto/arm-elf/include -c -fno-common -O0 -g
AFLAGS = -ahls -mapcs-32 -o crt.o
#LFLAGS = -Map rtc_clock.map -T2138_demo.cmd -Lc:\gccfd\yagarto\arm-elf\lib -lc -lg -lm
LFLAGS= -mcpu=arm7tdmi -Wl,-Map,rtc_clock.map -T2138_demo.cmd -nostdlib
LINK_LIBS= -Lc:\ccfd\yagarto\arm-elf\lib -lc
CPFLAGS = -O binary
HEXFLAGS = -O ihex
ODFLAGS = -x --syms
all: test
clean:
-rm crt.lst crt.o rtc_clock.o rtc_clock.out rtc_clock.map rtc_clock.dmp rtc_clock.bin
test: rtc_clock.out
$(CP) $(CPFLAGS) rtc_clock.out rtc_clock.bin
$(OD) $(ODFLAGS) rtc_clock.out > rtc_clock.dmp
$(CP) $(HEXFLAGS) rtc_clock.out rtc_clock.hex
rtc_clock.out: crt.o rtc_clock.o 2138_demo.cmd
# $(LD) $(LFLAGS) -o rtc_clock.out crt.o rtc_clock.o
$(CC) $(LFLAGS) -o rtc_clock.out crt.o rtc_clock.o $(LINK_LIBS)
crt.o: crt.s
$(AS) $(AFLAGS) crt.s > crt.lst
rtc_clock.o: rtc_clock.c
$(CC) $(CFLAGS) rtc_clock.c
and I can’t post the output. The forum software won’t allow it for some reason. It’s just a long list of errors like the following
undefined reference to `__ltdf2'
undefined reference to `__eqdf2'
and so on.
Ok, so I’ll post one of my makefiles.
##Makefile v2.0
CC = arm-elf-gcc
LD = arm-elf-ld
AR = arm-elf-ar
AS = arm-elf-as
CP = arm-elf-objcopy
OD = arm-elf-objdump
CFLAGS = -mcpu=arm7tdmi -I./ -c -fno-common -Os -g
AFLAGS = -ahls -mapcs-32 -o crt.o
LFLAGS = -mcpu=arm7tdmi -Wl,-Map,main.map,-TLPC2138_rom.ld -nostdlib
LINK_LIBS = -lc -lm -lg -lgcc
CPFLAGS = -O ihex
ODFLAGS = -x --syms
all: test
program:
-lpc21isp -verify main.hex /dev/ttyUSB0 115200 14746
clean:
-rm crt.lst crt.o system.o main.o main.out main.hex main.map main.dmp
test: main.out
@ echo "copying"
$(CP) $(CPFLAGS) main.out main.hex
$(OD) $(ODFLAGS) main.out > main.dmp
@ arm-elf-size main.out
main.out: crt.o system.o main.o LPC2138_rom.ld
@ echo "linking"
$(CC) $(LFLAGS) -o main.out crt.o system.o main.o $(LINK_LIBS)
crt.o: crt.s
@ echo "assembling"
$(AS) $(AFLAGS) crt.s > crt.lst
main.o: main.c
@ echo "compiling"
$(CC) $(CFLAGS) main.c
system.o: system.c
@ echo "compiling"
$(CC) $(CFLAGS) system.c
Note that is designed to work under Linux, not Windows so you’ll have to tweak the include paths as you were doing before. It is designed to compile two files “main.c” and “system.c” with a linker scrpt named “LPC2138_rom.ld” and an assembler startup file named “crt.s”. Hope this helps, I’ve been using this makefile for over a year with no problems.
Thanks inventore. I'll try that after work.inventore123:
Ok, so I’ll post one of my makefiles.
Inventore123 my friend! Thank you very much! I got it working finally.
I think I was pretty close, cause I didn’t change much. Just made a few changes with your makefile as a reference and tried it. It failed with a sbrk undefined reference to end. I googled for that and found that I had to add a “PROVIDE(end = .);” statement in the linker file. And that was it. Cured!
For anyone else grinding through this stuff, here’s my present makefile. No guarantees. It might still not be totally right, but it works good for now.
NAME = lcd4bit
CC = arm-elf-gcc
LD = arm-elf-ld
AR = arm-elf-ar
AS = arm-elf-as
CP = arm-elf-objcopy
OD = arm-elf-objdump
CFLAGS = -mcpu=arm7tdmi -Ic:/gccfd/yagarto/arm-elf/include -c -fno-common -O0 -g
AFLAGS = -ahls -mapcs-32 -o crt.o
LFLAGS= -mcpu=arm7tdmi -Wl,-Map,rtc_clock.map,-T2138_demo.cmd -nostdlib
LINK_LIBS= -lc -lm -lg -lgcc
CPFLAGS = -O binary
HEXFLAGS = -O ihex
ODFLAGS = -x --syms
all: test
clean:
-rm crt.lst crt.o rtc_clock.o rtc_clock.out rtc_clock.map rtc_clock.dmp rtc_clock.bin
test: rtc_clock.out
$(CP) $(CPFLAGS) rtc_clock.out rtc_clock.bin
$(OD) $(ODFLAGS) rtc_clock.out > rtc_clock.dmp
$(CP) $(HEXFLAGS) rtc_clock.out rtc_clock.hex
rtc_clock.out: crt.o rtc_clock.o 2138_demo.cmd
$(CC) $(LFLAGS) -o rtc_clock.out crt.o rtc_clock.o $(LINK_LIBS)
crt.o: crt.s
$(AS) $(AFLAGS) crt.s > crt.lst
rtc_clock.o: rtc_clock.c
$(CC) $(CFLAGS) rtc_clock.c
Nice to know you got it working