AVR32 Studio 2.1 Beta Newlib Addons problem

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trying to convert a stand-alone application on the UC3B1256 from 2.0.2 to 2.0.99 (2.1 beta) and found that the linker couldn't find the interrupt related routines like register_interrupt that used to be built into newlib.

Found this in the help:

The AVR32 GNU Toolchain v2.1 has removed some newlib addons files that were present in the previous versions: exceptions, interrupts and usart support. To minimize the effect on the Software Framework and on customers, these files have been added in the Software Framework as a module named NEWLIB_ADDONS.

# The NEWLIB_ADDONS module is organized as follows: under UTILS/NEWLIB_ADDONS/ the src code,
# under UTILS/NEWLIB_ADDONS/Build the scripts to build the libraries,
# under UTILS/LIBS/NEWLIB_ADDONS/INCLUDE the nlao interface header files.
# under UTILS/LIBS/NEWLIB_ADDONS/ the archive libs for AT32AP7, AT32UCR1, AT32UCR2:

* libnewlib_addons-at32xxxx-debug archive lib generated with -O0 -g (for debug)
* libnewlib_addons-at32xxxx archive lib generated with -O0 (no optimization)
* libnewlib_addons-at32xxxx-balanced_opt archive lib generated with -O2 (medium level optimization)
* libnewlib_addons-at32xxxx-speed_opt archive lib generated with -O3 (speed optimization)
* libnewlib_addons-at32xxxx-size_opt archive lib generated with -Os (size optimization)

OK, so I add:
"C:\Atmel\AT32UC3B-1.4.0\UTILS\NEWLIB_ADDONS\INCLUDE" to compiler include paths,
"C:\Atmel\AT32UC3B-1.4.0\UTILS\LIBS\NEWLIB_ADDONS\AT32UCR1\Releases\1.4.0" to linker library search path, and
"libnewlib_addons-at32ucr1-debug.a" to linker libraries

At the link stage (using command line avr32-gcc -L C:\Atmel\AT32UC3B-1.4.0\UTILS\LIBS\NEWLIB_ADDONS\AT32UCR1\Releases\1.4.0 -mpart=uc3b1256 -Wl,--gc-sections --rodata-writable --direct-data -oEnvProc.elf uc3serial.o uc3io.o envsup.o envproc.o commands.o cmex.o -l libnewlib_addons-at32ucr1-debug.a)

It gives the error:
c:/atmel/avr tools/avr32 toolchain/bin/../lib/gcc/avr32/4.2.2/../../../../avr32/bin/ld.exe: cannot find -l libnewlib_addons-at32ucr1-debug.a
collect2: ld returned 1 exit status
Build error occurred, build is stopped

Anyone know how to make this work?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

certsoft wrote:

At the link stage (using command line avr32-gcc -L C:\Atmel\AT32UC3B-1.4.0\UTILS\LIBS\NEWLIB_ADDONS\AT32UCR1\Releases\1.4.0 -mpart=uc3b1256 -Wl,--gc-sections --rodata-writable --direct-data -oEnvProc.elf uc3serial.o uc3io.o envsup.o envproc.o commands.o cmex.o -l libnewlib_addons-at32ucr1-debug.a)

It gives the error:
c:/atmel/avr tools/avr32 toolchain/bin/../lib/gcc/avr32/4.2.2/../../../../avr32/bin/ld.exe: cannot find -l libnewlib_addons-at32ucr1-debug.a
collect2: ld returned 1 exit status
Build error occurred, build is stopped

Anyone know how to make this work?

In GCC, when you use the linker switch -l to link in a library, GCC will actually try to find a filename of: lib.a. I believe this is discussed in the GNU ld user manual (which is a part of the GNU Binutils user manual).

So according to your linker command line you should remove this:

-l libnewlib_addons-at32ucr1-debug.a

and replace it with this:

-lnewlib_addons-at32ucr1-debug

Including removing that extra space between the 'l' and the library filename.

Give that a try and see if that works for you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:

In GCC, when you use the linker switch -l to link in a library, GCC will actually try to find a filename of: lib.a. I believe this is discussed in the GNU ld user manual (which is a part of the GNU Binutils user manual).

So according to your linker command line you should remove this:

-l libnewlib_addons-at32ucr1-debug.a

and replace it with this:

-lnewlib_addons-at32ucr1-debug

Including removing that extra space between the 'l' and the library filename.

Give that a try and see if that works for you.

Yes, that did it. I'm always amazed at what spastic behavior the gcc people build into their tools.

It now links OK. Unfortunately JTAGICE still doesn't work correctly running on Parallels on my Mac (like version 1.x did). Looking at all the bugs that were fixed in avr32program and avr32proxy I had hoped they had restored the previous functionality. I guess I'm stuck with using a "real" PC :(

Thanks for your help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

certsoft wrote:

Yes, that did it. I'm always amazed at what spastic behavior the gcc people build into their tools.

Every system has its quirks. GCC has quirks, but so do other compilers. It's helpful to remember that GCC quirks come from the general Unix/Linux community.

For example, in GCC and binutils, there is a library used to provide functions that work on multiple platforms. They call this library: libiberty.a. Weird name, huh? Until you realize that the linker command line to link in this library, the switch will look like this:

-liberty

Because using that library will free you from being tied down to platform-specific functionality. ;)

Y'know those Unix people can't pass up a good pun when they see one. :)

In the end, you learn the quirks, and you move on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:

In the end, you learn the quirks, and you move on.

While spending money to learn the quirks :(

Meanwhile, the JTAGICE MK11 situation continues to deteriote. With the new software & firmware it won't even work reliably on a "real pc" at this point.

Decided to spend the big bucks for a AVRONE and hope that it's not a big disappointment like the JTAGICE was.

Hoping to be able to actually work some billable hours on this project sometime this year, but not holding my breath.