Compile/link error, LUFA git-version, VirtualSerialMassStorage

[Hans Schou]

Hi Dean

I got the error below. Is there any other information I can add?

$ grep ^deb /etc/apt/sources.list | head -n 1

deb http://ftp.dk.debian.org/debian/ wheezy main non-free

$ avr-gcc -v

Using built-in specs.

COLLECT_GCC=avr-gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.0/lto-wrapper

Target: avr

Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr

Thread model: single

gcc version 4.7.0 (GCC) 

avr-gcc -c -pipe -gdwarf-2 -g2 -mmcu=at90usb1287 -fshort-enums -fno-inline-small-functions -fpack-struct -Wall -fno-strict-aliasing -funsigned-char -funsigned-bitfields -ffunction-sections -I. -I../../../../LUFA/.. -DARCH=ARCH_AVR8 -DBOARD=BOARD_USBKEY -DF_USB=8000000UL -DF_CPU=8000000UL -x c -Os -std=gnu99 -Wstrict-prototypes -DUSE_LUFA_CONFIG_HEADER -IConfig/  -MMD -MP -MF ../../../../LUFA/Drivers/USB/Class/Host/StillImageClassHost.d ../../../../LUFA/Drivers/USB/Class/Host/StillImageClassHost.c -o ../../../../LUFA/Drivers/USB/Class/Host/StillImageClassHost.o

 [LNK]     : Linking object files into "VirtualSerialMassStorage.elf"

avr-gcc -lm -Wl,-Map=VirtualSerialMassStorage.map,--cref -Wl,--gc-sections -Wl,--relax  -mmcu=at90usb1287  VirtualSerialMassStorage.o Descriptors.o Lib/DataflashManager.o Lib/SCSI.o ../../../../LUFA/Drivers/USB/Core/AVR8/Device_AVR8.o ../../../../LUFA/Drivers/USB/Core/AVR8/Endpoint_AVR8.o ../../../../LUFA/Drivers/USB/Core/AVR8/Host_AVR8.o ../../../../LUFA/Drivers/USB/Core/AVR8/Pipe_AVR8.o ../../../../LUFA/Drivers/USB/Core/AVR8/USBController_AVR8.o ../../../../LUFA/Drivers/USB/Core/AVR8/USBInterrupt_AVR8.o ../../../../LUFA/Drivers/USB/Core/AVR8/EndpointStream_AVR8.o ../../../../LUFA/Drivers/USB/Core/AVR8/PipeStream_AVR8.o ../../../../LUFA/Drivers/USB/Core/ConfigDescriptors.o ../../../../LUFA/Drivers/USB/Core/DeviceStandardReq.o ../../../../LUFA/Drivers/USB/Core/Events.o ../../../../LUFA/Drivers/USB/Core/HostStandardReq.o ../../../../LUFA/Drivers/USB/Core/USBTask.o ../../../../LUFA/Drivers/USB/Class/Common/HIDParser.o ../../../../LUFA/Drivers/USB/Class/Device/AudioClassDevice.o ../../../../LUFA/Drivers/USB/Class/Device/CDCClassDevice.o ../../../../LUFA/Drivers/USB/Class/Device/HIDClassDevice.o ../../../../LUFA/Drivers/USB/Class/Device/MassStorageClassDevice.o ../../../../LUFA/Drivers/USB/Class/Device/MIDIClassDevice.o ../../../../LUFA/Drivers/USB/Class/Device/RNDISClassDevice.o ../../../../LUFA/Drivers/USB/Class/Host/AndroidAccessoryClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/AudioClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/CDCClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/HIDClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/MassStorageClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/MIDIClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/PrinterClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/RNDISClassHost.o ../../../../LUFA/Drivers/USB/Class/Host/StillImageClassHost.o -o VirtualSerialMassStorage.elf

/usr/lib/gcc/avr/4.7.0/../../../avr/lib/avr51/crtusb1286.o: In function `__bad_interrupt':

../../../../crt1/gcrt1.S:195: relocation truncated to fit: R_AVR_13_PCREL against symbol `__vector_11' defined in .text.__vector_11 section in ../../../../LUFA/Drivers/USB/Core/AVR8/USBInterrupt_AVR8.o

collect2: error: ld returned 1 exit status

make[4]: *** [VirtualSerialMassStorage.elf] Error 1

make[4]: Leaving directory `/home/chlor/work/lufa-git/Demos/Device/ClassDriver/VirtualSerialMassStorage'

make[3]: *** [VirtualSerialMassStorage/] Error 2

[Dean Camera]

^&%#$&^#&^%#*ing Google Groups just ate my very long reply to this, so
this is attempt two. Sorry if it's shorted and less detailed.

Hans,

The short answer is that you will need to change this line in LUFA/
Build/lufa_build.mk:

BASE_LD_FLAGS := -lm -Wl,-Map=$(TARGET).map,--cref -Wl,--gc-sections -
Wl,--relax

To this:

BASE_LD_FLAGS := -lm -Wl,-Map=$(TARGET).map,--cref -Wl,--gc-sections

Due to a bug in your version of Binutils. If you know how to recompile
your own toolchain there's a patch for this in the Atmel Toolchain
packages ("307-binutils-fix-AVRTC-424.patch") to fix it, but the
alternative if you don't is just to disable linker relaxations via the
above modification. The problem is that the linker relaxations mode
(designed to slightly compact the code during linking, by replacing 4
byte CALL instructions with the 2 byte RCALL instructions where
possible) fails due to a bug in some circumstances, resulting in the
build failure you are seeing. Normally relaxations provides a small
but measurable benefit, but if you are using an unpatched linker it
can cause more problems than its worth.

I think I'll add in a list of common compile failures to the LUFA
documentation and perhaps add a LINKER_RELAXATIONS setting to the
build makefile to optionally turn this off on broken systems.

Cheers!
- Dean

On Sep 29, 10:54 am, Hans Schou <hans.sc...@gmail.com> wrote:
> Hi Dean
>
> I got the error below. Is there any other information I can add?
>
> $ grep ^deb /etc/apt/sources.list | head -n 1

> debhttp://ftp.dk.debian.org/debian/wheezy main non-free

[Hans Schou]

thanks, remove of "-Wl,--relax" is working ...with my broken/faulty debian package ;-)

Compile time 2½ minute.

I have filed a bug report to debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689223

The other solution with making a check for the broken package but the problem is also to remove that check again. It could be removed when squeeze (Debian stable releas) is outdated but that takes a long time...

/hans

2012/9/29 Dean Camera <abcmi...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To post to this group, send email to lufa-s...@googlegroups.com.
To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

[Dean Camera]

Great, I've added a LINKER_RELAXATIONS option to the build module
internally so that you will be able to compile with "make
LINKER_RELAXATIONS=N" or add the appropriate link to your project
makefile in the future to avoid this.

> Compile time 2½ minute.

Now that's ridiculous, it takes 8 seconds on my Windows machine for
the same demo, which is slow due to the use of the MinGW emulation of
the POSIX APIs that GCC needs. I can halve that time by comping under
native Linux as you are doing. Can you give an indication of what part
is taking so long? Is each step taking a long time, or is it a
particular file compilation or the linking stage that is slowing it
down?

Cheers!
- Dean

On Sep 30, 4:39 pm, Hans Schou <hans.sc...@gmail.com> wrote:
> thanks, remove of "-Wl,--relax" is working ...with my broken/faulty debian
> package ;-)
>
> Compile time 2½ minute.
>
> I have filed a bug report to debian:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689223
>
> The other solution with making a check for the broken package but the
> problem is also to remove that check again. It could be removed when
> squeeze (Debian stable releas) is outdated but that takes a long time...
>
> /hans
>

> 2012/9/29 Dean Camera <abcminiu...@gmail.com>

> > > debhttp://ftp.dk.debian.org/debian/wheezymain non-free

[Hans Schou]

2012/9/30 Dean Camera <abcmi...@gmail.com>

Great, I've added a LINKER_RELAXATIONS option to the build module
internally so that you will be able to compile with "make
LINKER_RELAXATIONS=N" or add the appropriate link to your project
makefile in the future to avoid this.

Sounds good.

I guess you have to make some code like:

if $(LINKER_RELAXATIONS) = "Y"

  and buggy-version-of-binutils-avr then

  say "Error, blah blah blah"

fi

> Compile time 2½ minute.

Now that's ridiculous, it takes 8 seconds on my Windows machine for
the same demo, which is slow due to the use of the MinGW emulation of
the POSIX APIs that GCC needs. I can halve that time by comping under
native Linux as you are doing. Can you give an indication of what part
is taking so long?

Yes, the hole part. Like:

  cd /

  make clean

  time make

This one is faster:

( cd Demos/Device/ClassDriver/VirtualSerialMassStorage/ ; make clean ; time make )

...

real    0m2.694s

user    0m2.212s

sys     0m0.312s

8 seconds!! That's ridiculous ;-)

So, a full compile on Windows will take:

  8/2.69*2½ = 7.4 minutes ?

best regards

Hans

[Dean Camera]

> I guess you have to make some code like:
>
> if $(LINKER_RELAXATIONS) = "Y"
> and buggy-version-of-binutils-avr then
> say "Error, blah blah blah"
> fi

Not yet, I've just added the raw option at the moment:

https://github.com/abcminiuser/lufa/commit/1fe273baed2a77c950b4f52a5402f0085d63c9e8

Adding detection of the faulty versions of binutils would slow down
execution a tiny bit - but the real problem is that I have no idea
exactly what versions of binutils breaks, and with what patches. The
best I can do is document all the common failures in the build section
of the manual and indicate the correct way to work around it.

> real 0m2.694s
> user 0m2.212s
> sys 0m0.312s

Are you compiling on a 286? That seems excessively slow. Try adding
"DEBUG_LEVEL = 0" to your makefile and see if that speeds things up a
bit.

Cheers!
- Dean

On Sep 30, 5:43 pm, Hans Schou <hans.sc...@gmail.com> wrote:
> 2012/9/30 Dean Camera <abcminiu...@gmail.com>

[Jim Paris]

Dean Camera wrote:
> > I guess you have to make some code like:
> >
> > if $(LINKER_RELAXATIONS) = "Y"
> > and buggy-version-of-binutils-avr then
> > say "Error, blah blah blah"
> > fi
>
> Not yet, I've just added the raw option at the moment:
>
> https://github.com/abcminiuser/lufa/commit/1fe273baed2a77c950b4f52a5402f0085d63c9e8
>
> Adding detection of the faulty versions of binutils would slow down
> execution a tiny bit - but the real problem is that I have no idea
> exactly what versions of binutils breaks, and with what patches. The
> best I can do is document all the common failures in the build section
> of the manual and indicate the correct way to work around it.
>
> > real 0m2.694s
> > user 0m2.212s
> > sys 0m0.312s
>
> Are you compiling on a 286? That seems excessively slow. Try adding
> "DEBUG_LEVEL = 0" to your makefile and see if that speeds things up a
> bit.

2.7 seconds is excessively slow? I'm not Hans, but on my system here
(Athlon II X250) a cache-warm (make clean; make) in the
VirtualSerialMassStorage takes 3 sec, 2.6 sec if I use DEBUG_LEVEL=0.
With -j2, it drops in half. That doesn't seem bad for 33 GCC runs.

-jim

[Dean Camera]

Dang, I read it as two minutes, not two seconds. In that case yes, I
think two seconds compilation time under a native Linux installation
would be acceptable ;).

- Dean

On Oct 4, 6:59 pm, Jim Paris <j...@jtan.com> wrote:
> Dean Camera wrote:
> > > I guess you have to make some code like:
>
> > > if $(LINKER_RELAXATIONS) = "Y"
> > >   and buggy-version-of-binutils-avr then
> > >   say "Error, blah blah blah"
> > > fi
>
> > Not yet, I've just added the raw option at the moment:
>

> >https://github.com/abcminiuser/lufa/commit/1fe273baed2a77c950b4f52a54...

[Hans Schou]

FYI

Version 2.23.1-1 of binutils-avr is now in Debian unstable.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689223#15

LINKER_RELAXATIONS=N is not needed any more.

/hans