Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
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.