Problems compiling program with new version Webbotlib

[KurtEck]

I am starting a real stipped down program, to first start working with XBEE then build up to a Brat Biped, with an Axon2.  I tried also building a striped down version of Raven with the same problem

I now receive comiler errors when I try building it:

avr-gcc -I"C:\My_Robots\DeBrat\..\webbotlib"  -mmcu=atmega640 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT DeBrat.o -MF dep/DeBrat.o.d  -c  ../DeBrat.c
avr-gcc -mmcu=atmega640 -Wl,-Map=DeBrat.map DeBrat.o   -L"C:\My_Robots\WebbotLib"  -lWebbot-ATMega640 -lc -lm  -o DeBrat.elf
C:\My_Robots\WebbotLib\libWebbot-ATMega640.a(segled.o): In function `marqueeIsActive':
/segled.h:86: multiple definition of `marqueeIsActive'
DeBrat.o:C:\My_Robots\DeBrat\..\webbotlib/sys/../segled.h:86: first defined here
C:\My_Robots\WebbotLib\libWebbot-ATMega640.a(segled.o): In function `marqueeSetCharDelay':
/segled.h:89: multiple definition of `marqueeSetCharDelay'
DeBrat.o:C:\My_Robots\DeBrat\..\webbotlib/sys/../segled.h:89: first defined here
C:\My_Robots\WebbotLib\libWebbot-ATMega640.a(segled.o): In function `marqueeSetEndDelay':
/segled.h:95: multiple definition of `marqueeSetEndDelay'
DeBrat.o:C:\My_Robots\DeBrat\..\webbotlib/sys/../segled.h:95: first defined here
C:\My_Robots\WebbotLib\libWebbot-ATMega640.a(segledMarquee.o): In function `marqueeIsActive':
/segled.h:86: multiple definition of `marqueeIsActive'
DeBrat.o:C:\My_Robots\DeBrat\..\webbotlib/sys/../segled.h:86: first defined here
C:\My_Robots\WebbotLib\libWebbot-ATMega640.a(segledMarquee.o): In function `marqueeSetCharDelay':
/segled.h:89: multiple definition of `marqueeSetCharDelay'
DeBrat.o:C:\My_Robots\DeBrat\..\webbotlib/sys/../segled.h:89: first defined here
C:\My_Robots\WebbotLib\libWebbot-ATMega640.a(segledMarquee.o): In function `marqueeSetEndDelay':
/segled.h:95: multiple definition of `marqueeSetEndDelay'
DeBrat.o:C:\My_Robots\DeBrat\..\webbotlib/sys/../segled.h:95: first defined here
make: *** [DeBrat.elf] Error 1
Build failed with 1 errors and 0 warnings...

[webgeek]

Snag the 1.13a release from here to get past that. The marquee stuff won't work yet, but you won't get any compilation errors:
http://sourceforge.net/projects/webbotavrclib/files/webbotavrclib-1.13a.zip/download

Mike

[KurtEck]

Thanks!

Kurt

[KurtEck]

Another hopefully quick question.

Is it assumed that if you are using webbotlib, that you will only have one C source file?   I am more used to doing my development by subdividing my project into smaller self contained things, where I define 2 files for it.  A header file .h that has the public defined stuff in it and a source C file that has the functionality in it.  But when I tried that, I ended up with lots of multiple defined objects...

Things like:
C:\My_Robots\DeBrat\..\webbotlib/sys/axon2.h:287: multiple definition of `led_off'
DeBrat.o:C:\My_Robots\DeBrat\..\webbotlib/sys/axon2.h:287: first defined here
DIYXBee.o: In function `configure_ports':

Note: I am not using any LED stuff in my new source file...

I will try adapting by including my source file at the end of the main one...

Kurt

[Admin]

For WebbotLib, I use one C file, and it #includes a butt-load of .h files to do my bidding.

Sure you're linking them right?

[Webbot]

Yeah, my Lib is based on the idea of one C file with many *.h files. The reason being that I was trying to keep it simple so that the user didn't need to set up a link process to bring in their own pre-compiled C programs which would be harder for newbies.

A more complete/complex answer - there are certain things that the library needs to know: like your processor speed for instance. By only having one C file then there can only be one setting for this from the current make invocation from AVRStudio. By using individual C files then it would be possible to compile them all using different processor speeds and then linking them together into one executable - resulting in a mess. There are also lots of #defines you can set in your main program that can then control some of the library operations. By allowing the user to have more than one C file then this can introduce other anomalies.
Currently I ship a library for each processor model ie ATMega640 and a sys/*.h that modifies it for a specific board. The 'sys' file can only be included once (by your main program). To allow for separate user C files then I would actually needs to distribute a library for every sys (board).  I don't really want to do that as the benefit of the way things currently work is that a user can create thir own sys file - say for their own design of ATMega168 $50 robot board.

The easiest answer is to rename your other *.c files as *.h files and then just include them in your main C file.

Of course if you have source files that do not call WebbotLib - lets say you have written a standalone PID function - then there is noting to stop you building these into a library of your own that is included by the linker.