Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
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) [details] The Makefile causing the error
Created an attachment (id=96680) [details] Example c-Code - can be used to re-create the bug
Created an attachment (id=96681) [details] 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) [details] 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) [details] 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) [details] 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.
(In reply to comment #23) > 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 > > thx
It seems, cross-compiling is completely broken. I tried - binutils built by crossdev for avr - bintuils built by crossdev for msp430 both say: "cannot open linker script file ldscripts/..." Please fix this! I need working crosscompilers. How can i help?
I see this problem as well. As suggested in other commments (e.g. comment #14), on my amd64 system, ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/avr/lib/ldscripts provides a workaround to the problem. I don't know much about how the crossdev support works in Gentoo, but it is an area I am somewhat interested in and would be willing to spend some time digging into if it would be helpful. From a brief look, it appears that crossdev automatically generates ebuilds for the cross-development toolchain specified, which are then installed. In comment #17 it is mentioned that a build outside of crossdev works correctly, so my first guess would be that the generated ebuilds are not getting the paths quite right and the solution would involve getting crossdev to generate "correct" ebuilds. Am I heading in the right direction with this? Is there anyone that is more familiar with how things work that could give me some pointers for making progress on this issue?
Looking into this in a (tiny) bit more depth today, I now see that the crosdev script links the standard toolchain ebuilds, so any change to ebuilds affects the host toolchains too. Those are presumably fine so don't want to meddle with them. I'm a little confused about the different paths involved. The symlinks are as follows: /usr/avr/lib --> /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts --> /usr/lib/binutils/avr/2.19/ldscripts Is it correect that: /usr/avr/lib is supposed to be the avr target root filesystem directory structure /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts is where binutils-config makes the symlink for the current binutils version to be used for builds for the avr target /usr/lib/binutils/avr/2.19/ldscripts is where the binutils build actually installs the file for the version (2.19) of the ebuild? If the above is correct, shouldn't the cross-toolchain linker be looking in /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts? I notice in binutils-config, that it appears that /usr/avr/lib/ldscripts will be forcibly removed (there is the line "rm -rf ${ROOT}/usr/${TARGET}/lib/ldscripts"). This is in binutils-config-1.9-r4, the most recent version I see in portage. It gets called during pkg_postinst, so if I rebuild the cross-binutils, it will remove the link I manually put in place. That link doesn't seem to be right, but how do I get the toolchain to look in the right place? I'm particuarlly concerned about the ebuild getting this right in part because I want to use dev-embedded/arduino, and as far as I can tell the arduino "IDE" does not allow me to specify an additional directory on the linker path, etc.
One last wild parting thought based on the analysis of the linker search path given in comment# 14. All the links in /usr/<CHOST>/<CTARGET>/lib are for binutils (at least for my crossdev -t avr setup). Should binutils-config just put these in /usr/<CHOST>/<CTARGET>/binutils-bin/lib instead? That seems like it would solve the problem.
(In reply to comment #29) > One last wild parting thought based on the analysis of the linker search path > given in comment# 14. All the links in /usr/<CHOST>/<CTARGET>/lib are for > binutils (at least for my crossdev -t avr setup). Should binutils-config just > put these in /usr/<CHOST>/<CTARGET>/binutils-bin/lib instead? That seems like > it would solve the problem. > Well the likning workaround is known already, if you really want to understand how stuff (don't) work, you should have a look et the eclasses all the magic is done there. The main problem I see is that no one in the toolchain maintainers care about the avr toolchain, or have no time to work on it. This workaroud is well known and would have been an easy fix, even if it just hides a more profund problem, which is that crossdev messes around in a broken way with a hell of symlinking in order to support multitarget and multislot stuff. AVR toolchain developpers moto : "crossdev is known to be badly broken, use a manualy built compiler with instructions from avrfraks.net or from the avr-libc documentation" This is sad, but this bug have been open since more than 2 yeas and half with no change. Developpers should better close it as WONTFIX as the avr toolchain is effectively unsupported. Best Aurélien
This change to binutils-config-1.9-r4 fixes it for me: *** /usr/bin/binutils-config Mon Oct 15 03:37:13 2007 --- /home/hb/binutils-config Tue Mar 3 09:40:06 2009 *************** *** 120,126 **** # LIBPATH=${LIBPATH:-/usr/lib/binutils/${TARGET}/${VER}} cd "${ROOT}/${LIBPATH}" || exit 1 ! if [[ ${TARGET} == ${HOST} ]] ; then dstlib=${ROOT}/usr/${HOST}/lib else dstlib=${ROOT}/usr/${HOST}/${TARGET}/lib --- 120,128 ---- # LIBPATH=${LIBPATH:-/usr/lib/binutils/${TARGET}/${VER}} cd "${ROOT}/${LIBPATH}" || exit 1 ! if [[ ${TARGET} == avr ]] ; then ! dstlib=${ROOT}/usr/${TARGET}/lib ! elif [[ ${TARGET} == ${HOST} ]] ; then dstlib=${ROOT}/usr/${HOST}/lib else dstlib=${ROOT}/usr/${HOST}/${TARGET}/lib Does anybody know a way to do this without having to make an explicit exception for avr? If not, perhaps this is the best solution. It certainly shouldn't hurt anything, and it solves the problem.
Or, here's an alternative patch that isn't avr specific. However, I don't know that this won't break some other platform [I'm not a Gentoo/binutils expert] so I'd be a bit careful with it. It may also break on installations which have old files lying around: *** /usr/bin/binutils-config Sun Feb 22 15:18:28 2009 --- /home/hb/binutils-config Tue Mar 3 09:43:56 2009 *************** *** 120,126 **** # LIBPATH=${LIBPATH:-/usr/lib/binutils/${TARGET}/${VER}} cd "${ROOT}/${LIBPATH}" || exit 1 ! if [[ ${TARGET} == ${HOST} ]] ; then dstlib=${ROOT}/usr/${HOST}/lib else dstlib=${ROOT}/usr/${HOST}/${TARGET}/lib --- 120,128 ---- # LIBPATH=${LIBPATH:-/usr/lib/binutils/${TARGET}/${VER}} cd "${ROOT}/${LIBPATH}" || exit 1 ! if [[ -d ${ROOT}/usr/${TARGET}/lib ]] ; then ! dstlib=${ROOT}/usr/${TARGET}/lib ! elif [[ ${TARGET} == ${HOST} ]] ; then dstlib=${ROOT}/usr/${HOST}/lib else dstlib=${ROOT}/usr/${HOST}/${TARGET}/lib
*** Bug 280148 has been marked as a duplicate of this bug. ***
hello. The bug is still here on my system. I'm using binutils-config-1.9-r4 (see comment #6). After reading comment #8, i can say that the link is indeed here with all needed scripts on my system: /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts: symbolic link to `/usr/lib/binutils/avr/2.19.1/ldscripts' Still following comment #8, i did the strace and grepped the output. Teh relevant part is here: 6800 open("ldscripts/avr6.x", O_RDONLY) = -1 ENOENT (No such file or directory) 6800 open("/usr/lib/gcc/avr/4.4.1/avr6/ldscripts/avr6.x", O_RDONLY) = -1 ENOENT (No such file or directory) 6800 open("/usr/lib/gcc/avr/4.4.1/../../../../avr/lib/avr6/ldscripts/avr6.x", O_RDONLY) = -1 ENOENT (No such file or directory) 6800 open("/usr/lib/gcc/avr/4.4.1/ldscripts/avr6.x", O_RDONLY) = -1 ENOENT (No such file or directory) 6800 open("/usr/lib/gcc/avr/4.4.1/../../../../avr/lib/ldscripts/avr6.x", O_RDONLY) = -1 ENOENT (No such file or directory) This bug is almost 3 years old.. my feeling is that most people end using one of the different workaround and stop complaining. Though the bug is quite a big "barrier to entry" for newcomers...
I too have the same issue. Ran crossdev -t avr -s4 today on my amd64 box and tried to compile some simple c as described at http://symbolx.org/robotics/107-arduinoavr-command-line-dev-environment The error I get is jon@gentoo-desktop ~/Documents/Projects/avr $ avr-gcc -DF_CPU=16000000UL -mmcu=atmega168 -o blink.out blink.c In file included from blink.c:2: /usr/lib/gcc/avr/4.4.1/../../../../avr/include/util/delay.h:90:3: warning: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" /usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No such file or directory
For those having the problem : i used the trick to add (by myself) one simple symbolic link, as specified in previous comments. And now it works.
I suspect, that SpanKY/Vapier is still waiting for information on how to reproduce. Is that it? Well, I will attach the output and the strace that show, what's going on and where it's going wrong. I think, that will give you all information on how to reproduce this error.
Created an attachment (id=208206) [details] output of "avr-gcc -v -mmcu=atmega128 test.c"
Created an attachment (id=208208) [details] strace of "avr-gcc-strace.txt avr-gcc -mmcu=atmega128 test.c"
Created an attachment (id=208210) [details] strace of "avr-ld -m avr5" Oh, I just realized, that it's even simpler to reproduce the error: avr-ld --verbose -m avr5 And I also found the reason, why only some hit the problem and why it's working if no "-m" switch is given to the linker. For avr2 (that is the default), there seems to be some internal linker script. The linker doesn't even try loading any external ldscript. So if you try to reproduce, make sure that you pass an -m switch and use something different from avr2. So here's another strace.
