Bugzilla Bug 147155

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5)
Gecko/20060910 Firefox/1.5.0.5
Build Identifier: 

Hi everyone,

When compiling c-code for an "AVR5"-type-target (such als all the newer
ATMegas), the linking stage fails with

/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No
such file or directory

I'm currently running binutils-2.16.1-r2 - the error did not occur with the
last
version, the number of which I unfortunately can't tell anymore (reinstall)

Changing the -mmcu definition to a different AVR type (e.g. at90s8535 which is
an avr4) makes the compile run smoothly.

Linking /usr/lib/binutils/avr/2.16.1/ldscripts into my source directory works
as
well (this is my current workaround) - so it looks as if there is only a wrong
path typo somewhere. Sorry, I'm not really into this stuff, so I'm handing this
over to you guys.

I will attach an example C-code (doing perfectly nothing :)) and a Makefile.
See
the Makefile for the mmcu-switch.

Best Regards, Heiko

(Hope I did't forget anything - this is my first bug report)

Reproducible: Always

Steps to Reproduce:
1. emerge crossdev
2. unmask binutils-config-1.9-r1 + set PORTDIR_OVERLAY
3. run crossdev -t avr
4. change into source folder with main.c and Makefile from Attachments
5. run make (of course need to "make clean" after a successful approach)

Actual Results:  
Compiling stage went well.

Linking stage aborts with the following:

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -g   -Os -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o 
-std=gnu99 -DF_CPU=12000000 -MD -MP -MF .dep/main.elf.d main.o   --output
main.elf -Wl,-Map=main.map,--cref    -lm
/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No
such file or directory
make: *** [main.elf] Error 1


Expected Results:  
Correctly link the code :)

well - do you need this for anything? (same bug occurs on my Laptop, same
gentoo-version, same USE-flags, only different CPU: Intel Pentium III-M)

Portage 2.1.1 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17.6
i686)
=================================================================
System uname: 2.6.17.6 i686 AMD Athlon XP-M
Gentoo Base System version 1.12.4
Last Sync: Mon, 11 Sep 2006 07:50:01 +0000
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=athlon-xp -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo "
LINGUAS=""
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="x86 X alsa apache2 apm arts avi berkdb bitmap-fonts cdparanoia cdr cli
crypt dlloader dri dvd dvdread eds elibc_glibc emboss encode esd foomaticdb
fortran gdbm gif gimpprint gnome gpm gstreamer gtk gtk2 icq imlib
input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog
jabber jpeg kernel_linux libg++ libwww mad mbox mikmod motif mp3 mpeg msn
ncurses nls nptl nptlonly ogg opengl oss pam pcre pdf pdflib perl png postfix
pppd print python qt3 qt4 quicktime readline reflection sasl sdl session spell
spl ssl tcpd tetex tif truetype truetype-fonts type1-fonts userland_GNU
video_cards_apm video_cards_ark video_cards_ati video_cards_chips
video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev
video_cards_glint video_cards_i128 video_cards_i740 video_cards_i810
video_cards_imstt video_cards_mga video_cards_neomagic video_cards_nsc
video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge
video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb
video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng
video_cards_v4l video_cards_vesa video_cards_vga video_cards_via
video_cards_vmware video_cards_voodoo vim vorbis win32codecs xml xmms xorg xv
yahoo zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

Created an attachment (id=96679) [edit]
The Makefile causing the error

Created an attachment (id=96680) [edit]
Example c-Code - can be used to re-create the bug

Created an attachment (id=96681) [edit]
Sorry, this one is the failing Makefile...

...the other one has the different MCU-type selection...

# avr-gcc -Wall -mmcu=atmega8 test.c -o test.elf
/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr4.x: No
such file or directory

With the symlink workaround as suggested by OP I get:
/usr/libexec/gcc/avr/ld: skipping incompatible
/usr/lib/gcc/avr/3.4.6/../../../../avr/lib/avr4/libc.a when searching for -lc
/usr/libexec/gcc/avr/ld: skipping incompatible
/usr/lib/gcc/avr/3.4.6/../../../../avr/lib/libc.a when searching for -lc
/usr/libexec/gcc/avr/ld: cannot find -lc

Trying to compile then link in separate stages, I get:
# avr-ld test.o -o test.elf
test.o: In function `main':
test.c:(.text+0x0): undefined reference to `__stack'
test.c:(.text+0x2): undefined reference to `__stack'

Recompiling avr-libc by hand using "./configure --host=avr --prefix=/usr" AND
using the symlink method does operate correctly. The manual recompilation was
suggested by http://bugs.gentoo.org/show_bug.cgi?id=144645 - this is a separate
issue that happened to occur at the same time.

Steps to Reproduce:
1. emerge crossdev
2. run crossdev -t avr
3. try to build any code that has been tested to work on other platforms

Expected Results:
Correct compilation and linking.

Actual results:
Failed to link after compilation.


# emerge --info
Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3,
2.6.17-gentoo-r8 i686)
=================================================================
System uname: 2.6.17-gentoo-r8 i686 AMD Athlon(tm) XP 3200+
Gentoo Base System version 1.12.4
Last Sync: Wed, 13 Sep 2006 09:50:01 +0000
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.3.5-r2, 2.4.3-r3
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo
/etc/texmf/web2c"
CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://ftp.citylink.co.nz/gentoo
http://mirror.pacific.net.au/linux/Gentoo"
LC_ALL="en_US.utf8"
LINGUAS="en"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/portage-xgl
/usr/portage/local/layman/erazor"
SYNC="rsync://sempron/gentoo-portage"
USE="x86 3dnow 3dnowext X a52 aac acl acpi alsa arts asf audiofile
bash-completion berkdb bitmap-fonts bzip2 cairo calendar cdr cli crypt cups
dbus dlloader dri dvd dvdr dvdread elibc_glibc emboss encode esd fam fbsplash
ffmpeg firefox flac foomaticdb fortran ftp gdbm gecko-sdk gif gpm gtk hal idn
imagemagick imap imlib input_devices_keyboard input_devices_mouse ip1000 ipv6
isdnlog jabber java javascript jpeg kde kdeenablefinal kdexdeltas kerberos
kernel_linux libg++ libwww linguas_en lirc_devices_streamzap mad mikmod mime
mmx mmxext mng mono mozilla mozsvg mp3 mpeg mplayer msn ncurses nls nptl
nptlonly nsplugin nvidia offensive ogg ogvorbis opengl oss pam pcre pdf perl
png posix ppds pppd python qt qt3 qt4 quicktime rdesktop readline reflection
samba sdl servicetools session spell spl sse ssl svg tcpd theora tiff truetype
truetype-fonts type1-fonts udev unicode unstablecups usb userland_GNU
video_cards_nv video_cards_nvidia video_cards_vesa vorbis win32codecs wxwindows
xcomposite xine xinerama xml xml2 xorg xosd xpm xscreensaver xv xvid zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

fixed with binutils-config-1.9-r2 ... symlinked ldscripts into the gcc libexec
path

Hi again,

Short form: binutils-config-1.9-r4 re-introduced this bug. Same story as above.

Long form: Currently I am using avr-gcc 3.4.6, avr-libc 1.4.5, avr-binutils
2.16.1-r3 and, as already mentioned above, binutils-config-1.9-r4. The bug
occurs exactly as above, linking stage fails only with avr5, same workaround as
above.

Sorry I can't test binutils-config-1.9-r3 - there is no ebuild for it any more.
I can't remember if I rebuild the toolchain while -r3 was installed on my
system.

Yours, Heiko

(In reply to comment #6)
> Sorry I can't test binutils-config-1.9-r3 - there is no ebuild for it any more.

You can find the ebuild for binutils-config-1.9-r3 there :
http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/sys-devel/binutils-config/binutils-config-1.9-r3.ebuild?rev=1.2

Denis.

works just fine for me ... the ldscripts link is created in the correct place:
/usr/$CHOST/$CTARGET/lib/ldscripts

in my case:
/usr/x86_64-pc-linux-gnu/avr/lib/ldscripts

which points to:
/usr/lib/binutils/avr/2.16.1/ldscripts

run `strace -f -o out avr-gcc foo.c` and see where it is looking for
"ldscripts" and where it isnt finding it

Denis: Thanks, I will try that one tomorrow.

vapier: Yes, the links are created correctly, plus I can't see any differences
in the paths between avr4 and avr5 (-mmcu=at90s8535 and -mmcu=atmega32 in my
case) but still avr4 works while avr5 fails.

avr-gcc looks for ldscripts directory in:
/usr/i686-pc-linux-gnu/avr/binutils-bin/2.16.1/../../../../avr/lib/ldscripts
/usr/i686-pc-linux-gnu/avr/binutils-bin/2.16.1/../lib/ldscripts
/usr/avr/lib/ldscripts
/usr/libexec/gcc/avr/ldscripts
/usr/libexec/gcc/avr/../lib/ldscripts

...none of which exist.
Funny enough, if compiling with -mmcu=atmega32, avr-gcc then (=after searching
for the ldscripts directory) tries to open avr5.x in various other directories
and cannot find it.
If compiling exactly the same source with -mmcu=at90s8535, avr-gcc does not try
to open avr4.x (which would be the correct ldscript for at90s8535)

I will attach both strace logs, so you can find more information in there, plus
I will do some more testing (rebuilding, binutils-config-r3) tomorrow.

Best Regards, Heiko

Created an attachment (id=119567) [edit]
This is the "crashing" strace log - created with -mmcu=atmega32

Full command was: strace -f -o strace.avr5 avr-gcc -o main.elf main.c
-mmcu=atmega32

Created an attachment (id=119569) [edit]
This is the "working" strace log - created with -mmcu=at90s8535

Full command was: strace -f -o strace.avr4 avr-gcc -o main.elf main.c
-mmcu=at90s8535

*** Bug 179824 has been marked as a duplicate of this bug. ***

Reopen wrt Bug 179824.

I've been trying to dig into this a bit. Here's what I've found:

The actual location of the ldscripts is: 
/usr/lib64/binutils/avr/${BVER}/ldscripts

There is a symlink to this:
/usr/${CHOST}/${CTARGET}/lib/ldscripts ->
/usr/lib/binutils/avr/${BVER}/ldscripts

Probably the symlink is what should be utilized.



Now, some variables seen in the ld source:

program_name = argv[0]
   /usr/libexec/gcc/avr/ld
which is a symlink to
   /usr/${CHOST}/${CTARGET}/binutils-bin/${BVER}/ld
BINDIR = $(bindir), set by configure --bindir=${BINPATH} in the eclass.
   /usr/${CHOST}/${CTARGET}/binutils-bin/${BVER}
tooldir = $(exec_prefix)/$(target_alias)
   /usr/avr
TOOLBINDIR = $(tooldir)/bin
   /usr/avr/bin
SCRIPTDIR = $(tooldir)/lib
   /usr/avr/lib


Next, the following are the locations ld tries to look for the ldscripts
directory, in order, during the set_script_dir() function (ldmain.c) [1]:

(see [2] for make_relative_prefix() documentation. Note that it expands
symlinks.)

1.  make_relative_prefix (program_name, BINDIR, SCRIPTDIR)
   /usr/${CHOST}/${CTARGET}/binutils-bin/${BVER}/../../../../avr/lib
   -- or --
   /usr/avr/lib

2.  make_relative_prefix (program_name, TOOLBINDIR, SCRIPTDIR)
   /usr/${CHOST}/${CTARGET}/binutils-bin/${BVER}/../lib
   -- or --
   /usr/${CHOST}/${CTARGET}/binutils-bin/lib

   This comes really close... one more '../' would make it. If BINPATH was set
   without ${BVER}, it would work. However, we of course want the ${BVER} in 
   there.

3.  SCRIPTDIR is tried directly
   /usr/avr/lib

4.  the directory of the ld exe derived from program_name
   /usr/libexec/gcc/avr

5.  (the directory of the ld exe)../lib
   /usr/libexec/gcc/lib

Both of Heiko's strace logs fit this. Note that even the "working" log does not
find ldscripts, and it fact it never tries to open a linker script. It "works"
for some other reason.


I have only one suggestion for a solution, and no opinion on whether it is
correct: have binutils-config create a symlink:
/usr/${CTARGET}/lib/ldscripts -> /usr/${CHOST}/${CTARGET}/lib/ldscripts

This will work with case #1 (and #3).

I created this symlink on my system with CHOST=x86_64_pc-linux-gnu and
CTARGET=avr. It of course works.


Thanks, I hope this helps.


[1] CVS, but set_scripts_dir() hasn't changed in a long time:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldmain.c?rev=1.123&content-type=text/x-cvsweb-markup&cvsroot=src
[2] libiberty documentation:
http://gcc.gnu.org/onlinedocs/libiberty/Functions.html#index-make_005frelative_005fprefix-115

One more thought just occurred to me, as I noticed the similarity between the
two paths in the symlink:
/usr/${CTARGET}/lib/ldscripts -> /usr/${CHOST}/${CTARGET}/lib/ldscripts

Maybe everything should go in /usr/${CHOST}/${CTARGET}, and have a symlink:
/usr/{CTARGET} -> /usr/${CHOST}/${CTARGET}

That seems fairly elegant to me, but I am not knowledgeable about cross
development toolchains.

It works with CVS-version 1.9 of binutils-config-1.9 (and re-emerging
cross-avr/binutils).  The difference to the current CVS-version 1.10 is
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/binutils-config/files/binutils-config-1.9?r1=1.9&r2=1.10
and has been introduced by bug #171486.

I got the same problem with different versions of binutils and gcc, always used
avr-libc-1.4.6 .
I tried a local build as described in
http://www.nongnu.org/avr-libc/user-manual/install_tools.html
and everything works fine, so I guess some paths get mixed up while installing
files.
Adding the path to the linkerscript with "-L" option can be used as a
workaround.

Just wanted to add that this bug is still present. Two days ago I've emerged
crossdev and did "crossdev -t avr". Here are the versions I have now:

sys-devel/crossdev 0.9.18-r4
cross-avr/avr-libc 1.4.6
cross-avr/binutils 2.18-r1
cross-avr/gcc 4.2.2

I've tried to compile a simple program to atmega8 and I got:

$ avr-gcc -mmcu=atmega8 -std=c99 -Os -Wall -fshort-enums -o hello.elf hello.o
/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr4.x: No
such file or directory

I'm going to attach an strace.

Created an attachment (id=134031) [edit]
strace log

strace -f -o LOG  avr-gcc  -mmcu=atmega8 -std=c99 -Os -Wall -fshort-enums 
-pipe -o hello.elf hello.o

Forgot to mention before, but this bug is also cited at this forum topic:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=336170

*** Bug 203859 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> One more thought just occurred to me, as I noticed the similarity between the
> two paths in the symlink:
> /usr/${CTARGET}/lib/ldscripts -> /usr/${CHOST}/${CTARGET}/lib/ldscripts
> 
> Maybe everything should go in /usr/${CHOST}/${CTARGET}, and have a symlink:
> /usr/{CTARGET} -> /usr/${CHOST}/${CTARGET}
> 
> That seems fairly elegant to me, but I am not knowledgeable about cross
> development toolchains.
> 

In BUG 171486 "Comment #9 From SpanKY", he mentions something that seems to be
closely related to what you are talking about:

  "looks like i broke that by accident when doing the bin/lib cleanup with"
  "/usr/$CTARGET/ -> /usr/$CHOST/$CTARGET/"

Here is a workaround that worked for me (I am super newbie so it probably is
really bad and ugly) but if there is more newbies out there that just need to
get something to work (while waiting for a nice patch).

ln -s /usr/i686-pc-linux-gnu/avr/lib/ldscripts /usr/libexec/gcc/avr/ldscripts

(In reply to comment #23)
> Here is a workaround that worked for me (...) that just need to
> get something to work (while waiting for a nice patch).
> 
> ln -s /usr/i686-pc-linux-gnu/avr/lib/ldscripts /usr/libexec/gcc/avr/ldscripts

Likewise, I have another nice solution. Just add
-L/usr/i686-pc-linux-gnu/avr/lib (as suggested at comment #17) to your compile
command.