View topic - Undefined Reference Makefile Issue?

Search

Undefined Reference Makefile Issue?

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR studio 4 forum

Author

Message

elrichindy

Posted: Feb 08, 2010 - 05:59 AM

Joined: Jan 04, 2008
Posts: 52
Location: Melbourne, Australia

Hi All,

I have not had a need to use an external makefile until recently when I decided to use MS Visual Studio instead of AVR Studio.

So I created a Makefile using Mfile but have had some issues using it in AVR Studio. I have attached said makefile.

I had a search through the forums and many of the posts don't come to a definitive solution? or one that wasn't helpful to me.

To start, can anyone recommend a good reference to start learning about all the bits in a makefile. I understand the basics but don't know what all the little symbols really are doing.

so my errors, which do not appear when using the default makefile are :

<excluding c\..\ directory structure from each>
dsscamera.c:237: undefined reference to `set_next_adc'

dsscamera.c:48: undefined reference to `__eerd_word_m168'
dsscamera.c:49: undefined reference to `__eerd_word_m168'
dsscamera.c:51: undefined reference to `__eerd_block_m168'

The First error is from a Macro in a header file

Code:

#define set_next_adc(next_ADC){\

   ADC_control = next_ADC;\

}

I'm using a Macro as I'm trying to create Modularised code and this function is used in an ISR. I haven't used inline here as it is a separate file so I don't think the compiler will optimise it correctly. obviously inline static won't work because of it being in a different file.
Unless anyone knows a way to handle the option of inline code in an ISR from a separate source file without using a macro? would be nice as I have a few functions that will go in there...

ADC_control is an extern variable listed, I initially thought this was where my error was as i forgot to include it as an extern variable in my header file, but didn't explain the other ones.

The second set of errors originate from calls to the <avr/eeprom.h> file.

I assume this is some library linking issue but am not too sure.

Thank you for your help oh wonderful magical forum guru answerer. Hopefully by the end of this I'll be some kind of makefile god.. doubt that though...

update 1: nuts, sorry, just realised I posted this in the AVR Studio forum.. not sure if that is ok?

update2:
I was playing around with the makefile to get the error outputs to work with visual studio(still not working btw) from the original:

Code:

# Compile: create object files from C source files.

$(OBJDIR)/%.o : %.c

   @echo

   @echo $(MSG_COMPILING) $<

   $(CC) -c $(ALL_CFLAGS) $< -o $@

To this found on the forum:

Code:

# Compile: create object files from C source files.

$(OBJDIR)/%.o : %.c

        @echo

        @echo $(MSG_COMPILING) $<

        @echo '$(CC) -c $(ALL_CFLAGS) $< -o $@ 2> errors.txt' > Test.bat

        @echo 'sed "s/c:\([0-9]*\)/c(\1)/" errors.txt' >> Test.bat

        Test.bat

and now the
dsscamera.c:237: undefined reference to `set_next_adc'
has gone away... still left with the others though.
Don't know why this may of helped though...

Cheers

E

_________________
"I'll tolerate assignments in Loops, but this kind of lewd behaviour in IF's will not be tolerated"-Seems unfair, Loops bribed him...

Last edited by elrichindy on Feb 08, 2010 - 07:32 AM; edited 1 time in total

Koshchi

Posted: Feb 08, 2010 - 07:14 AM

Joined: Nov 17, 2004
Posts: 9102
Location: Vancouver, BC

Quote:

I'm using a Macro as I'm trying to create Modularised code and this function is used in an ISR.

But it is not a function, it is a macro, which means that set_next_adc(x) will be replaced with:

Code:

{

     ADC_control = x;

}

Quote:

dsscamera.c:48: undefined reference to `__eerd_word_m168'

And where is__eerd_word_m168 defined?

_________________
Regards,
Steve A.

The Board helps those that help themselves.
wylfwt?

JohanEkdahl

Posted: Feb 08, 2010 - 07:23 AM

Joined: Mar 27, 2002
Posts: 9264
Location: Lund, Sweden

Quote:

The second set of errors originate from calls to the <avr/eeprom.h> file.

I assume this is some library linking issue but am not too sure.

No, this is an error at compile time (notice that the error message starts with naming the .c source file.

Quote:

now the
dsscamera.c:237: undefined reference to `set_next_adc'
has one away... still left with the others though.
Don't know why this may [have] helped though...

The only difference between the two seems to be that the second filters out message stuff that is still generated by the compiler. Did you look in the errors.txt file? Do you understand what the second version of the compile rule is doing? Are you fluent with SED? If not, then return to the first version and work on fixing the problems instead of potentially hiding them.

elrichindy

Posted: Feb 08, 2010 - 08:07 AM

Joined: Jan 04, 2008
Posts: 52
Location: Melbourne, Australia

Hi Steve,
Exactly what I want, sorry for calling a macro a function.
__eerd_word_m168 is concatenated in the eeprom.h file via a bunch of macros and if elseif's, pulled out the ones I use as:

Code:

#elif defined (__AVR_ATmega168P__)

# define _EEPROM_SUFFIX  _m168p

#define _EEPROM_CONCAT1(s1, s2)     s1 ## s2

#define _EEPROM_CONCAT2(s1, s2)     _EEPROM_CONCAT1 (s1, s2)

#define eeprom_read_byte      _EEPROM_CONCAT2 (__eerd_byte, _EEPROM_SUFFIX)

#define eeprom_read_word      _EEPROM_CONCAT2 (__eerd_word, _EEPROM_SUFFIX)

#define eeprom_read_block     _EEPROM_CONCAT2 (__eerd_block, _EEPROM_SUFFIX)

And from a file search is specified in libc.a, so maybe this is not being properly referenced in my makefile..if so how do I fix this?

Hi Johan,

Yes, I agree and as stated have no clue as to what they are doing at the moment. Would be grateful for an explanation, though I am currently just reading some makefile information sources I googled, any particular one recommended?.
So, before you posted your comment I removed it and for some reason the set_next_adc is still not there... the only other thing I can think of that I changed was I performed a make clean, though that isn't a part of visual studio clean so I compiled in VS and it was gone from there too?
I also briefly added full directory paths to the source files, but it didn't work so changed it back to normal, maybe a stray space or something??

Still getting the other undefined references though.

I don't know if the error.txt and test.bat files will be of any relevance but have listed the information contained below:

errors.txt wrote:

In file included from serial.c:14:
defines.h:10:9: error: no macro name given in #define directive
In file included from c:/winavr-20100110/lib/gcc/../../avr/include/inttypes.h:37,
from c:/winavr-20100110/lib/gcc/../../avr/include/avr/sfr_defs.h:126,
from c:/winavr-20100110/lib/gcc/../../avr/include/avr/io.h:99,
from defines.h:11,
from serial.c:14:
c:/winavr-20100110/lib/gcc/../../avr/include/stdint.h:122: error: duplicate 'unsigned'
c:/winavr-20100110/lib/gcc/../../avr/include/stdint.h:122: error: two or more data types in declaration specifiers

test.bat wrote:

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./serial.lst -std=gnu99 -MMD -MP -MF .dep/serial.o.d serial.c -o serial.o 2> errors.txt
sed "s/c:\([0-9]*\)/c(\1)/" errors.txt

_________________
"I'll tolerate assignments in Loops, but this kind of lewd behaviour in IF's will not be tolerated"-Seems unfair, Loops bribed him...

elrichindy

Posted: Feb 09, 2010 - 12:36 AM

Joined: Jan 04, 2008
Posts: 52
Location: Melbourne, Australia

Anyone out there to assist?
Still not sure on what is wrong with my makefile?

Code:

dsscamera.c:48: undefined reference to `__eerd_word_m168' 

dsscamera.c:49: undefined reference to `__eerd_word_m168' 

dsscamera.c:51: undefined reference to `__eerd_block_m168'

note the Duplicate unsigned errors in my errors.txt file posted previously have been fixed. I don't think the test.bat and errors.txt are of any help as I was playing around with a few things at the time, only left with these undefined's now.

Appreciate help as I would like to move on with other things.

Thank you in advance.

Elric

_________________
"I'll tolerate assignments in Loops, but this kind of lewd behaviour in IF's will not be tolerated"-Seems unfair, Loops bribed him...

JohanEkdahl

Posted: Feb 09, 2010 - 05:22 AM

Joined: Mar 27, 2002
Posts: 9264
Location: Lund, Sweden

Quote:

__eerd_word_m168 is concatenated in the eeprom.h

Looking at a WinAVR20090313 installation, I do not have a single instance of the string "__eerd_word_m168" in my eeprom.h . I have no macro named _EEPROM_CONCAT2 (mine is simply CONCAT2). Etc etc.. This means something has changed in avr-libc lately re EEPROM access.

I see you're on 20100110 which was a bit messy, and there was a new release under the same name. One thing to try might be to download the current version of the 20100110 release and see if that helps. There is another thread here somewhere that talks about how to tell which of the 20100110 versions you have installed, but I can't locate it right now.

Other than that I don't have any ideas, and I'm not so keen on upgrading to 20100110 right now.

elrichindy

Posted: Feb 09, 2010 - 06:31 AM

Joined: Jan 04, 2008
Posts: 52
Location: Melbourne, Australia

I downloaded the latest WINAVR20100110 one a just over a week ago and did notice a thread which mentions some issues with 2010, might look further in to it.

But..
The default makefile in AVR studio works just fine? only my mfile one fails.
I might grab WINAVR2009 and give that a go later to see if it makes a difference.

Johan wrote:

I do not have a single instance of the string "__eerd_word_m168" in my eeprom.h

It is not directly in eeprom.h, but concatenated from the specifying the processor(in my case the m168p)and adding it to __eerd_<type>_
__eerd_word_m16 does appear in libc.a though if you perform a text search on the file.

_________________
"I'll tolerate assignments in Loops, but this kind of lewd behaviour in IF's will not be tolerated"-Seems unfair, Loops bribed him...

JohanEkdahl

Posted: Feb 09, 2010 - 07:29 AM

Joined: Mar 27, 2002
Posts: 9264
Location: Lund, Sweden

Regardless of where __eerd_word_m168 is, it is a fact that eg my concatenation macros in eeprom.h are different from yours. A downgrade to 20090313 might be a solution. If so, be sure to give EW a heads-up about a possible bug/misbuild in the current WinAVR.

clawson

Posted: Feb 09, 2010 - 09:40 AM

Joined: Jul 18, 2005
Posts: 33138
Location: (using avr-gcc in) Finchingfield, Essex, England

I took the Makefile in the first post and then built on my system with WinAVR2010:

Code:

D:\test>make

-------- begin --------

avr-gcc (WinAVR 20100110) 4.3.3

Copyright (C) 2008 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: dsscamera.c

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-

adhlns=./dsscamera.lst  -std=gnu99 -MMD -MP -MF .dep/dsscamera.o.d dsscamera.c -

o dsscamera.o

Compiling C: adcdsscamera.c

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-

adhlns=./adcdsscamera.lst  -std=gnu99 -MMD -MP -MF .dep/adcdsscamera.o.d adcdssc

amera.c -o adcdsscamera.o

Compiling C: serial.c

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-

adhlns=./serial.lst  -std=gnu99 -MMD -MP -MF .dep/serial.o.d serial.c -o serial.

o

Compiling C: pcserialcomms.c

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-

adhlns=./pcserialcomms.lst  -std=gnu99 -MMD -MP -MF .dep/pcserialcomms.o.d pcser

ialcomms.c -o pcserialcomms.o

Compiling C: twi.c

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-

adhlns=./twi.lst  -std=gnu99 -MMD -MP -MF .dep/twi.o.d twi.c -o twi.o

Compiling C: ADXL345.c

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-

adhlns=./ADXL345.lst  -std=gnu99 -MMD -MP -MF .dep/ADXL345.o.d ADXL345.c -o ADXL

345.o

Linking: dsscamera.elf

avr-gcc -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char -fu

nsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adh

lns=dsscamera.o  -std=gnu99 -MMD -MP -MF .dep/dsscamera.elf.d dsscamera.o adcdss

camera.o serial.o pcserialcomms.o twi.o ADXL345.o --output dsscamera.elf -Wl,-Ma

p=dsscamera.map,--cref     -lm

Creating load file for Flash: dsscamera.hex

avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock dsscamera.elf dsscamera.hex

Creating load file for EEPROM: dsscamera.eep

avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \

        --change-section-lma .eeprom=0 --no-change-warnings -O ihex dsscamera.el

f dsscamera.eep || exit 0

Creating Extended Listing: dsscamera.lss

avr-objdump -h -S -z dsscamera.elf > dsscamera.lss

Creating Symbol Table: dsscamera.sym

avr-nm -n dsscamera.elf > dsscamera.sym

Size after:

AVR Memory Usage

----------------

Device: atmega88p

Program:      80 bytes (1.0% Full)

(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)

(.data + .bss + .noinit)

-------- end --------

The only difference is that I didn't actually have the .c files so I created them with:

Code:

D:\test>touch dsscamera.c adcdsscamera.c serial.c pcserialcomms.c twi.c ADXL345.c

and put a blank main() in the first.

So I guess we need a small test file that shows access to the EEMEM stuff that triggers this error?

BTW I can't help noticing that the -mmcu in this is atmega88p so why would the original message have mentioned 168 anyway if it was simply concatenating the MCU name?

_________________

clawson

Posted: Feb 09, 2010 - 09:51 AM

Joined: Jul 18, 2005
Posts: 33138
Location: (using avr-gcc in) Finchingfield, Essex, England

PS I tried to break it with:

Code:

#include <avr/eeprom.h>

uint8_t e_var EEMEM;

volatile uint8_t dest;

int main(void) {

   eeprom_write_byte(&e_var, 37);

   dest = eeprom_read_byte(&e_var);

}

but:

Code:

D:\test>make

-------- begin --------

avr-gcc (WinAVR 20100110) 4.3.3

Copyright (C) 2008 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: dsscamera.c

avr-gcc -c -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char

-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-

adhlns=./dsscamera.lst  -std=gnu99 -MMD -MP -MF .dep/dsscamera.o.d dsscamera.c -

o dsscamera.o

Linking: dsscamera.elf

avr-gcc -mmcu=atmega88p -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char -fu

nsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adh

lns=dsscamera.o  -std=gnu99 -MMD -MP -MF .dep/dsscamera.elf.d dsscamera.o adcdss

camera.o serial.o pcserialcomms.o twi.o ADXL345.o --output dsscamera.elf -Wl,-Ma

p=dsscamera.map,--cref     -lm

Creating load file for Flash: dsscamera.hex

avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock dsscamera.elf dsscamera.hex

Creating load file for EEPROM: dsscamera.eep

avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \

        --change-section-lma .eeprom=0 --no-change-warnings -O ihex dsscamera.el

f dsscamera.eep || exit 0

Creating Extended Listing: dsscamera.lss

avr-objdump -h -S -z dsscamera.elf > dsscamera.lss

Creating Symbol Table: dsscamera.sym

avr-nm -n dsscamera.elf > dsscamera.sym

Size after:

AVR Memory Usage

----------------

Device: atmega88p

Program:     166 bytes (2.0% Full)

(.text + .data + .bootloader)

Data:          1 bytes (0.1% Full)

(.data + .bss + .noinit)

EEPROM:        1 bytes (0.2% Full)

(.eeprom)

(remember this is using the Makefile in the 1st post so it would seem to be exonerated - I wonder if it's mis-use of the EEPROM API?)

_________________

elrichindy

Posted: Feb 09, 2010 - 10:14 AM

Joined: Jan 04, 2008
Posts: 52
Location: Melbourne, Australia

oooooooohhhhhhhhh s*&^#

clawson wrote:

BTW I can't help noticing that the -mmcu in this is atmega88p so why would the original message have mentioned 168 anyway if it was simply concatenating the MCU name?

Thank you..I do feel stupid now though.
You hit the nail on the head there clawson.
The main prototype is running on the 168p, but my test board is an 88p so I have been swapping back and forth which isn't an issue with just using AVR studio and default makefile.
To add to this, To get the intellisense in Visual Studio to stop showing errors with use of calls to SFR's (PORTn, TIMSK etc) I needed to add the below to my define.h file:

Code:

 #ifndef __AVR_ATmega168P__

#define __AVR_ATmega168P__

#endif

which was causing issues at compile time.
after I changed it all to 168 or 88 it works.
So thank you, thank you, thank you.
For some reason I was looking for a complex answer for a simple solution and din't even check mcu..retard...

Elric

Edit:
I should note to anyone else that happens across this post who does not know, that the precompiler creates the __AVR_<MCU> hence why I need to define it for MS VS's intellisense and error stuff as it's done at compile time.

_________________
"I'll tolerate assignments in Loops, but this kind of lewd behaviour in IF's will not be tolerated"-Seems unfair, Loops bribed him...

JohanEkdahl

Posted: Feb 09, 2010 - 06:08 PM

Joined: Mar 27, 2002
Posts: 9264
Location: Lund, Sweden

Redefining / messing with the defines for the AVR model is something I would definitively recommend against. I sort of sense that I can not talk you out of it Elric, but I leave this post here so that others will at least see a recommendation against it.

The internal workings of the avr-libc include files are complex enough so that any mistake with tampering with them can lead to severe unwanted effects. You where lucky to get a hard error that stopped a successful build. I can easily imagine that some such manouvres can lead to a seemingly successful build, but with severely f*cked up [1] code generated.

Glad that you found the problem, though!

--------------------
Endnotes:
[1] Read this as "Gently Caressed Up" if you feel like it. Very Happy

elrichindy

Posted: Feb 10, 2010 - 02:20 AM

Joined: Jan 04, 2008
Posts: 52
Location: Melbourne, Australia

I agree with you Johan.
I've just been playing around to get VS working nicely and done some short time(I hope) hacks until I figure out a better way.
But yes, all should listen to Johan unless you have a specific need to. And then when you have that need(which you will probably never ever have) do your research to understand what is really going on, or you might end up recalling millions of cars like Toyota Smile

.

Elric

_________________
"I'll tolerate assignments in Loops, but this kind of lewd behaviour in IF's will not be tolerated"-Seems unfair, Loops bribed him...

martonmiklos

Posted: Jun 27, 2010 - 09:39 PM

Joined: Oct 21, 2009
Posts: 19

Hello all,

I have a problem with the

Code:

undefined reference to __eerd_byte_m*

issue.

I am using Ubunutu 10.04 with the shipped avrlibc, etc.
For building I am using Code::Blocks.
By default it links with the avr-g++ with the following command:

Code:

avr-g++ -L/usr/lib/avr/lib  -o bin/avr.elf .objs/adc.o .objs/global.o .objs/i2c.o .objs/main.o .objs/motor.o .objs/serial.o .objs/servo.o   -mmcu=atmega32 

I have opened the /usr/lib/avr/lib/libc.a but I have not found any references to __eerd_byte_m32, only found __eerd_byte_t13, and __eerd_byte_t2313, etc.

If I force the linker to link with the /usr/lib/avr/lib/avr5/libc.a it works fine. It is not so comfortable.

In the previous version of Ubuntu it worked fine.
What did changed? The directory structure of the libc's lib dir? Or the libc.a itself?
Is there any way to specify to the linker to search recursively in the -L directrories?

JohanEkdahl

Posted: Jun 27, 2010 - 10:19 PM

Joined: Mar 27, 2002
Posts: 9264
Location: Lund, Sweden

Please avoid hijacking unrelated threads in the future.

Quote:

In the previous version of Ubuntu it worked fine.
What did changed?

How did you install avr-gcc?
Did you just type avr-gcc into Synaptic and install? (bad, these are know to notoriously not being up to date re eg patches etc)
Or did you locate Bingos build script, or the ready-to-install package that comes put of it? (good, Bingo put a lot of work into it, and it is patched regularly)

clawson

Posted: Jun 28, 2010 - 10:47 AM

Joined: Jul 18, 2005
Posts: 33138
Location: (using avr-gcc in) Finchingfield, Essex, England

As it's Ubuntu just go here:

www.wrightflyer.co.uk/avr-gcc/

That gets you EEPROM support as up to date as the one in WinAVR.

_________________

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR studio 4 forum

AVRFreaks.net

Search