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 attachment 96679 [details] The Makefile causing the error
Created attachment 96680 [details] Example c-Code - can be used to re-create the bug
Created attachment 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 attachment 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 attachment 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 attachment 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 attachment 208206 [details] output of "avr-gcc -v -mmcu=atmega128 test.c"
Created attachment 208208 [details] strace of "avr-gcc-strace.txt avr-gcc -mmcu=atmega128 test.c"
Created attachment 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.
(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 > > As of binutils-2.20, this did not work for me. I needed to create the symlink as follows: ln -s /usr/i686-pc-linux-gnu/avr/lib/ldscripts /usr/i686-pc-linux-gnu/avr/binutils-bin/2.20/ldscripts This *really* ought to be fixed!
if you got stuck, you just can make this symlink in your project dir (where you Makefile situete or from where you run avr-gcc): $ cd project_path $ ln -s /usr/i686-pc-linux-gnu/avr/lib/ldscripts
(In reply to comment #42) > if you got stuck, you just can make this symlink in your project dir (where you > Makefile situete or from where you run avr-gcc): > $ cd project_path > $ ln -s /usr/i686-pc-linux-gnu/avr/lib/ldscripts > Depending on which versions of things you have, the symlink might need to go different places. Here's how to get it right no matter what your situation is: locate [[name of missing file]] strace [[gcc link command, from your makefile]] 2>&1 | grep [[name of missing file]] ln -s [[directory containing missing file]] [[one of the places gcc looked]] In my case, it was locate avr5 strace avr-gcc etc etc etc 2>&1 | grep avr5 ln -s /usr/lib/binutils/avr/2.19/ldscripts /usr/lib/gcc/avr/4.3.2/avr51 and then everything worked.
the bug is still present with the toolchain you got today with "crossdev avr", that is : Tue Apr 6 01:55:16 2010 >>> cross-avr/binutils-2.20.1 Tue Apr 6 02:02:35 2010 >>> cross-avr/gcc-4.4.3 Tue Apr 6 02:06:00 2010 >>> cross-avr/avr-libc-1.6.8 Tue Apr 6 02:09:54 2010 >>> cross-avr/gcc-4.4.3
For the record, the one that has worked for me today was: ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts/ /usr/avr/lib/ldscripts (and it is independant from various versions)
(In reply to comment #45) > For the record, the one that has worked for me today was: > ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts/ /usr/avr/lib/ldscripts > > (and it is independant from various versions) > this solution works for me also.
(In reply to comment #46) > (In reply to comment #45) > > For the record, the one that has worked for me today was: > > ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts/ /usr/avr/lib/ldscripts > > > > (and it is independant from various versions) > > > > this solution works for me also. > I've installed avr-g++ with #crossdev --b -2.20.51.0.8 --g 4.4.1 --without-headers --target avr -s4 I get the error /usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No such file or directory #ln -s /usr/lib/binutils/avr/2.20.51.0.8/ldscripts /usr/avr/lib/ldscripts this solution works for me.
Workaround with link works also with me, but WHY is this bug still open after more than 3,5 years? Is it this hard to add creation of this link in ebuild or any other place?
Created attachment 243009 [details, diff] change ld's $(scriptdir) to the actual path where the ldscripts will be installed binutils-2.20.1 attempts to locate the ldscripts directory via three mechanisms: 1. Assuming the relative directory hierarchies at the time of `configure` or `make` are still relevant (which it uses to construct a relative path from argv[0] after $PATH expansion and resolving all symbolic links) 2. Assuming the ldscripts are in the absolute path $(toolpath)/lib/ldscripts as specified at compile time. ($(toolpath) is derived from the --exec-prefix and --target configure options) 3. Assuming ldscripts was placed in the same directory as the `ld` binary, to support running `ld-new` directory from the build directory. The toolchain-binutils eclass manages to violate all these assumptions with the way it manipulates the binutils installation for multislot support: A. During install but not compile, $(tooldir) is overridden by $LIBPATH. B. The contents of the $LIBPATH/lib (including the ldscripts directory) are moved up one directory to $(LIBPATH). Since the `ld` binary is installed to the directory as specified with configure --binpath=..., both A and B stops options 1 & 2 from locating ldscripts. Furthermore, since toolchain-binutils.eclass guarantees that $BINPATH != $LIBPATH, so option 3 will never locate the installed ldscripts either. The fix modifies binutil's ld/Makefile.in to point $(scriptdir) to the actual path in which the eclass will install ldscripts, which happens to be $(libdir). The fix is safe for both native binutils and cross-compiled binutils. Incidentally, this change actually fixes ldscripts lookup with USE=multislot for the native toolchain to match the version of `ld` that was invoked. Currently, `ld` picks up ldscripts from /usr/$CHOST/lib/ldscripts regardless of which version of ld was launched. If binutils-2.20 was the default as set by binutils-config but /usr/$CHOST/binutils-bin/2.19/ld was involved, ld would still use the 2.20 scripts. With the change and both binutils were recompiled, ld 2.19 would use the 2.19 scripts and 2.20 would use the 2.20 scripts, which IMHO is a better behavior.
Looks like a patch is in place. Please fix this so we can have a sane environment.
*** Bug 340114 has been marked as a duplicate of this bug. ***
Soon, this bug will be 4 years old. @maintainer: please do something about it! The solutions provided in comment #49 looks fine to me.
I can confirm that the patch from comment #49 works without any problems.
Patch from comment #49 works for me too.
I can confirm this is still a problem on amd64, i'm using binutils 2.20.1-r1. This error happens here with the arduino IDE when i try to compile a sketch. I used the symlink workaround for now -> ln -s ../../lib/binutils/avr/2.20.1/ldscripts/ ldscripts in the /usr/avr/lib dir. I didn't tried the fix from comment 49 still but i guess it will work since 3 users report it working and no one report problems with it.
binutils 2.21 still fails: $ avr-ld -mavr5 avr-ld: cannot open linker script file ldscripts/avr5.x: No such file or directory
*** Bug 348991 has been marked as a duplicate of this bug. ***
(In reply to comment #56) > binutils 2.21 still fails: > $ avr-ld -mavr5 > avr-ld: cannot open linker script file ldscripts/avr5.x: No such file or > directory > Changes mentioned in comment #49 still work for binutils-2.21. Only the line numbers have changed.
quickfix for gcc 4.4.4-r2, binutils 2.20.1-r1: /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.20.1 $ s ln -sf /usr/lib/binutils/avr/2.20.1/ldscripts ldscripts
Just wanted to add that this is still an issue. Compile Output: avr-gcc -g -Os -Wall -mmcu=atmega168 -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm -o initialload.o initialload.c ../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o /usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No such file or directory collect2: ld returned 1 exit status make: *** [initialload.hex] Error 1 ----- Version: [ebuild R ] cross-avr/binutils-2.21.1 USE="nls -multislot -multitarget -test -vanilla" 0 kB [1] [ebuild R ] cross-avr/avr-libc-1.7.0 USE="-doc" 0 kB [1] [ebuild R ] cross-avr/gcc-4.5.2 USE="nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -fortran -gcj -graphite -gtk -hardened -libffi -lto -mudflap -multilib -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" 0 kB [1] ------ However, once I do the symlink, I get another error: avr-gcc -g -Os -Wall -mmcu=atmega168 -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm -o initialload.o initialload.c ../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o /usr/libexec/gcc/avr/ld: cannot find crtm168.o: No such file or directory collect2: ld returned 1 exit status make: *** [initialload.hex] Error 1
I just got hit by this bug as well... Same as Brandon Penglase, adding a symlink just introduces a new error I have the following ebuild's built (with crossdev for the AVR related stuff): [ebuild R ] sys-devel/binutils-config-2-r1 0 kB [0] [ebuild R *] cross-avr/avr-libc-1.7.0 USE="-doc" 0 kB [1] [ebuild R ] sys-devel/binutils-2.21.1 USE="nls -multislot -multitarget -test -vanilla" 0 kB [0] [ebuild R ] cross-avr/binutils-2.21.1 USE="nls -multislot -multitarget -test -vanilla" 0 kB [1] [ebuild R ] sys-devel/gcc-4.4.5 USE="fortran mudflap nls nptl objc (-altivec) -bootstrap -build -doc -fixed-point -gcj -graphite -gtk (-hardened) (-libffi) (-multilib) -multislot -nocxx -nopie -nossp -objc++ -objc-gc -openmp -test -vanilla" 27 kB [?=>0] [ebuild R ] cross-avr/gcc-4.3.6 USE="nls nptl (-altivec) -bootstrap -build -doc -fixed-point -fortran -gcj -gtk -hardened -libffi -mudflap (-multilib) -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -openmp -test -vanilla" 0 kB [1] I am cross-compiling from MIPS to AVR, but my problems are the same as everyone elses.
This affects me too.
Same here for Arduino Mega2560, /usr/libexec/gcc/avr/ld: crtm2560.o: No such file: No such file or directory
I've tried re-emerging arduino and get the following error although it finished installing anyway! BUILD SUCCESSFUL Total time: 10 seconds >>> Source compiled. >>> Test phase [not enabled]: dev-embedded/arduino-0021 >>> Install arduino-0021 into /var/tmp/portage/dev-embedded/arduino-0021/image/ category dev-embedded * Applying arduino-script-0021.patch ... [ ok ] chmod: cannot access `/var/tmp/portage/dev-embedded/arduino-0021/image//usr/share/arduino-0021/hardware/libraries': No such file or directory fperms failed >>> Completed installing arduino-0021 into /var/tmp/portage/dev-embedded/arduino-0021/image/ I got the "ld" for avr cannot find linker script "avr5.x" error so I did ln -s /usr/lib/binutils/avr/2.21.1/ldscripts /usr/avr/lib/ldscripts and now I get the /usr/libexec/gcc/avr/ld: cannot find crtm328p.o: No such file or directory error instead. I also tried doing ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts /usr/avr/lib/ldscripts but I get the same error.
I am getting sick of this peristing bug, I shall get on with it and try to get a patch to fix the damn thing. This time even symlink of '-L' don't help, which is very very odd.
The error about *.so files is to do with https://bugs.gentoo.org/show_bug.cgi?id=378387. the multilib hack suggested there + the symlink => working compiler.
Well, fixing this in crossdev is not quite appropriate, the symlink can be added to 'toolchain-binutils.eclass' or otherwise the problem can be fixed with a patch to binutils source code. essentially what has to be done is figure out what really goes wrong here. 'toolchain-binutils.eclass' does quite a lot of tricks, so may be the fault is there. I have also tried to to do `env USE=vanilla crossdev -t avr -s0` and it failed, there are quite a few patches being applied to it ... hell knows what's going on to be honest - so perhaps the painless option is to add a condition to the eclass. Yet another fix would be to make eselect-binutils handle this, which I see being quite smart. The it would actually put the 'ldscripts' symlink into '/usr/avr/lib/' whenever the binutils version is being switched. This really sounds more like a smarty feature :))
(In reply to comment #69) > Well, fixing this in crossdev is not quite appropriate, the symlink can be > added to 'toolchain-binutils.eclass' or otherwise the problem can be fixed with > a patch to binutils source code. comment 49 seems to explain the situation quite well. binutils doesn't look for the script files at the location they are actually installed to by the ebuild, but at some other location, which, as far as I understand comment 49, is wrong even if one use a cross-compiling toolchain. I wish, SpanKY would comment about the statements in comment 49. However, he prefers not to communicate. Only user discussion here. Or did I miss anything? Cross-compiling is a part of gentoo, that is AFAIK not supported with so much effort as we'd wish to be. However, if the claims of comment 49 are true, this bug is not entirely cross-compiling related, and should treated differently.
I just tried this again last night (as I finally have the time to get back to my MCU), so here's the latest versions I'm running: cross-avr/avr-libc - 1.7.0 cross-avr/binutils - 2.21.53.0.2 cross-avr/gcc - 4.5.3-r1 ---- The symlink corrected the "cannot find linker script avr5.x", however I'm still getting the error on my last post: "/usr/libexec/gcc/avr/ld: cannot find crtm168.o: No such file or directory" -- I did find that symlinking /usr/avr/lib/avr5/crtm168.o into the directory with the code, it does seem to work at that point. Is there another symlink missing? ---- I'm willing to help get this thing sorted out, so I'm willing to test and try anything.
> The symlink corrected the "cannot find linker script avr5.x", however I'm still > getting the error on my last post: > "/usr/libexec/gcc/avr/ld: cannot find crtm168.o: No such file or directory" please try my patch: https://378387.bugs.gentoo.org/attachment.cgi?id=285553&action=diff&collapsed=&context=patch&format=raw&headers=1 That's to do with #378387, I verified and it works. You may wish to do cd /tmp/ git clone git://git.overlays.gentoo.org/proj/crossdev.git curl "https://378387.bugs.gentoo.org/attachment.cgi?id=285553&action=diff&collapsed=&context=patch&format=raw&headers=1" -O crossdev-378387.patch cd crossdev git apply /tmp/crossdev-378387.patch sudo cp ./crossdev /usr/local/bin/crossdev-test crossdev -C avr crossdev-test -t avr I have noticed that with '--stable' it fails to compile 'dev-embedded/avr-libc'. The patch basically adds a condition to not force 'USE=-multilib' for AVR target. This flag gives a bad effect for most of the other target, but it's needed to produce libgcc for all AVR sub-architectures.
Created attachment 285635 [details] Log of commands+crossdev build I followed your directions (minus curl, had to use wget instead), it seemed to compile file, however, I'm still getting "/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No such file or directory". Attached file is all of the commands and resulting output from following what you said to do.
Slight correction. I just tested this a little more (actually compiling and uploading code). Even though I still needed to put the symlink in place, once I did that, I no longer got the error about not finding crtm168.o, and when it compiled, and uploaded, it actually ran correctly (before I would just get "ba" repeating out over the serial port, instead of my expected output). So it seems we're now back to the original posting, and still need the symlink, but it now produces working code, and no other errors, at least for me.
Cross-compiling with CHOST=x86_64 and ARCH=avr, I have encountered /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.22/ld: \ cannot find crtm32.o: No such file or directory Details follow: I am trying to build the command line code that ships with the Open-USB-IO (ATMega 128 based) development board. I used "crossdev -t avr" to build the toolchain. Running make (which utilizes the shipped Makefile) runs the loader with command: avr-gcc usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o \ usbdrv/main.o user_code.o -Wl -Map,open-usb-io-firmware.map \ --cref -mmcu=atmega32 -o open-usb-io-firmware.elf This produces the following error messages: /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.22/ld.elf: \ cannot open linker script file ldscripts/avr5.x: \ No such file or directory collect2: ld returned 1 exit status Some web research finds two solutions (both of which work) using command: ln -s /usr/lib/binutils/avr/2.22/ldscripts /usr/avr/lib/ldscripts ln -s /usr/x86_64-pc-linux-gnu/avr/lib/ldscripts \ /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.22/ldscripts" After either of these fixes, a new error appears: avr-gcc usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o \ usbdrv/main.o user_code.o -Wl,-Map,open-usb-io-firmware.map \ --cref -mmcu=atmega32 -o open-usb-io-firmware.elf /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.22/ld: \ cannot find crtm32.o: No such file or directory collect2: ld returned 1 exit status The missing file (crtm32.0) exists at /usr/avr/lib/avr5/crtm32.o The linker command is: avr-gcc usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o \ usbdrv/main.o user_code.o -Wl,-Map,open-usb-io-firmware.map \ --cref -mmcu=atmega32 -o open-usb-io-firmware.elf The above command has been tried with each of the following additions: -L /usr/avr/lib/avr5/ -L /usr/avr/lib/ -L /usr/avr/ -L /usr/ but crtm32.o is still not found. Note: The avr toolchain has been rebuilt with crossdev -C avr crossdev -t avr Comment: It seems that crossdev need to create the symlink show above. Question: Any suggestions on accessing the missing crtm32.o avr/ -L ct2: ld returned 1 exit status ### /usr/ ### /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.22/ld.elf: cannot find crtm32.o: No such file or directory collect2: ld returned 1 exit status
My avr toolchain uses GNU Binutils 2.22 and gcc 4.5.3-r2 # using strace with avr/ld, I found the following attempts to open crtm32.o access("/usr/lib/gcc/avr/4.5.3/crtm32.o", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/gcc/avr/4.5.3/../../../../avr/lib/avr/4.5.3/crtm32.o", R_OK) = -1 ENOENT (No such file or directory) access("/usr/lib/gcc/avr/4.5.3/../../../../avr/lib/crtm32.o", R_OK) = -1 ENOENT (No such file or directory) # normalizing the above addresses to remove occurrences of "../" gives: access("/usr/lib/gcc/avr/4.5.3/crtm32.o", R_OK) ... access("/usr/avr/lib/avr/4.5.3/crtm32.o", R_OK) ... access("/usr/avr/lib/crtm32.o", R_OK) ... # experimentaion shows that crtm32.o is found # if either of the following symlinks is created ln -s /usr/avr/lib/avr5/crtm32.o /usr/avr/lib/crtm32.o ln -s /usr/avr/lib/avr5 /usr/avr/lib/avr/4.5.3
(In reply to comment #76) > ln -s /usr/avr/lib/avr5/crtm32.o /usr/avr/lib/crtm32.o > > ln -s /usr/avr/lib/avr5 /usr/avr/lib/avr/4.5.3 Well, this is not a proper fix, it will only work for avr5 and will not work at all for others. You need to apply the patch form here https://bugs.gentoo.org/show_bug.cgi?id=378387 (see my previous reply https://bugs.gentoo.org/show_bug.cgi?id=147155#c68).
I have the same two problems: 1) the missing linker script, I fixed it with "default-script" switch, e.g, in my makefile LDFLAGS=-Wl,-Map,$(TRG).map,--default-script=/usr/lib64/binutils/avr/2.22/ldscripts/avr4.x -mmcu=$(MCU) \ 2) missing crtm8515.o /usr/libexec/gcc/avr/ld: cannot find crtm8515.o: No such file or directory I really want to help fix this! Is there anything I can do?
The only thing I found in /usr/portage/eclass was was related to both "crossdev" and "avr" was this (around line 1109) if is_crosscompile ; then # When building a stage1 cross-compiler (just C compiler), we have to # disable a bunch of features or gcc goes boom local needed_libc="" case ${CTARGET} in *-linux) needed_libc=no-fucking-clue;; *-dietlibc) needed_libc=dietlibc;; *-elf|*-eabi) needed_libc=newlib;; *-freebsd*) needed_libc=freebsd-lib;; *-gnu*) needed_libc=glibc;; *-klibc) needed_libc=klibc;; *-uclibc*) needed_libc=uclibc;; *-cygwin) needed_libc=cygwin;; mingw*|*-mingw*) needed_libc=mingw-runtime;; avr) confgcc+=" --enable-shared --disable-threads";; esac if [[ -n ${needed_libc} ]] ; then if ! has_version ${CATEGORY}/${needed_libc} ; then confgcc+=" --disable-shared --disable-threads --without-headers" elif built_with_use --hidden --missing false ${CATEGORY}/${needed_libc} crosscompile_opts_headers-only ; then confgcc+=" --disable-shared --with-sysroot=${PREFIX}/${CTARGET}" else confgcc+=" --with-sysroot=${PREFIX}/${CTARGET}" fi fi
(In reply to comment #79) > The only thing I found in /usr/portage/eclass was was related to both > "crossdev" and "avr" was this (around line 1109) > > > > if is_crosscompile ; then > # When building a stage1 cross-compiler (just C compiler), we have to > # disable a bunch of features or gcc goes boom > local needed_libc="" > case ${CTARGET} in > *-linux) needed_libc=no-fucking-clue;; > *-dietlibc) needed_libc=dietlibc;; > *-elf|*-eabi) needed_libc=newlib;; > *-freebsd*) needed_libc=freebsd-lib;; > *-gnu*) needed_libc=glibc;; > *-klibc) needed_libc=klibc;; > *-uclibc*) needed_libc=uclibc;; > *-cygwin) needed_libc=cygwin;; > mingw*|*-mingw*) needed_libc=mingw-runtime;; > avr) confgcc+=" --enable-shared --disable-threads";; > esac > if [[ -n ${needed_libc} ]] ; then > if ! has_version ${CATEGORY}/${needed_libc} ; then > confgcc+=" --disable-shared --disable-threads > --without-headers" > elif built_with_use --hidden --missing false > ${CATEGORY}/${needed_libc} crosscompile_opts_headers-only ; then > confgcc+=" --disable-shared > --with-sysroot=${PREFIX}/${CTARGET}" > else > confgcc+=" --with-sysroot=${PREFIX}/${CTARGET}" > fi > fi sorry, in file "toolchain.eclass"
In /usr/portage/eclass/toolchain-funcs.sh (line 348) this is the only thin related to avr and crossdev. tc-ninja_magic_to_arch() { ninj() { [[ ${type} == "kern" ]] && echo $1 || echo $2 ; } local type=$1 local host=$2 [[ -z ${host} ]] && host=${CTARGET:-${CHOST}} case ${host} in alpha*) echo alpha;; arm*) echo arm;; avr*) ninj avr32 avr;; bfin*) ninj blackfin bfin;; cris*) echo cris;; hppa*) ninj parisc hppa;; i?86*)
I build the complete toolchain using these instructions http://www.nongnu.org/avr-libc/user-manual/install_tools.html I used the following versions: binutils-2.22.tar.bz2 gcc-4.6.2.tar.bz2 avr-libc-1.8.0.tar.bz2 Thereafter, I tried it out with my avr project and it work (that is, it solved my problem with linker scripts and object file). I think that cross compiling as many targets as gentoo does is extremely hard. This bug is probably very hard to solve, and I have very much respect for the people who create the toolchains. I just wanted to test if it works to build it outside portage and give alternative advice for the newbies who hit this bug.
I thought that was already fixed but apparently it's not :( Is there any progress on this bug?
no :-(
Created attachment 308991 [details, diff] Crossdev AVR Multilib Patch (Updated) Hokey, So.... I recently built a new computer, and had to set back up my AVR toolchain again. Here is what I did to get it working again: 1: Followed the instructions from comment 72 on this bug, however, use the updated patch attached to this comment when needed. I found that instead of the patch needing to start on line 711, it starts on 827. I don't take credit for this, it's Ilya Dmitrichenko's patch, just updated for more recent crossdev. 2. I needed to apply the symlink from comment 27, which stems from comment 15. Once I did this, I was able to compile and upload a program with no issue. For reference, step 2 above fixes this bug (not finding avr5), however once that it done, it "introduces" bug 377039, or part of it, where I get "/usr/libexec/gcc/avr/ld: cannot find crtm168.o: No such file or directory". Thats where step one comes in, where gcc is forced to have multilib turned on for the avr target. I think this bug and bug 377039 are co-bugs, more then one before another. This is what I found to work for me, hopefully we can get a solution to kill both of these bugs and get everyone happy :)
Created attachment 309069 [details, diff] Creates ldscripts symlink on AVR target
Created attachment 309071 [details] EBuild that applies the patches to crossdev Ok, so I figured I would create another patch to apply the symlink, which is attachment 309069 [details, diff]. Then I figured I would create an ebuild that combines both patches to create a crossdev that installs a working environment (at least that applies the fixes that have been found in this bug thread). Steps to use (This assumes you already have a local overlay in use): 1. mkdir -p /usr/local/portage/sys-devel/crossdev/files 2. cp -R /usr/portage/sys-devel/crossdev/* /usr/local/portage/sys-devel/crossdev/ 3. cd /usr/local/portage/sys-devel/crossdev 4. wget/curl this ebuild into that directory 5. wget/curl the two previous patches into the files directory 6. ebuild crossdev-20120305-r1.ebuild digest If target is already installed: 7. crossdev -C avr 8. crossdev -t avr At this point, it should compile, there will be an extra output when it finishes stating that it's creating the symlink, and you should be good to go. I have no idea if any of this is "proper", but I figure it's a step further then this bug has been in a (seemingly) long time. Also note, I set the version to a revision of the current build, so if a newer version comes out that doesn't include any fixes, crossdev will be broken again.
(In reply to comment #83) > I thought that was already fixed but apparently it's not :( > Is there any progress on this bug? definitely broken.
Note, bumping the version of the previously attached ebuild to the latest version in portage (crossdev-20120531), still applied cleanly with the patches I submitted in the previous posts. As of now, my code compiles cleanly, and runs fine on my ATMega168.
Thank you, Brandon! Your patches made it all compile for me again. I didn't read the bug report as a whole, but is there some reason (still?) not to commit this?
Could you please stop posting patches to crossdev that create symlinks that shouldn't be created? The symlink is a WORKAROUND. It's not supposed to be there. Please read and understand comment 49. Also consider that a patch has been posted along with comment 49, which fixed binutils and makes it looks for the script in the directory they are actually installed in. Did anybody even try that patch? Did you have problems with that patch? Command 49 and the atteched patch is much closer to a proper fix of the problem than the symlink workaround. The symlink is like having a horse to pull your car since the car's engine is broken. As to why there is no fix in the portage tree: As was mentioned in Bug 348991: SpanKY has a lot of other stuff to do to which is obviously of higher priority. He's so busy, he can't even respond here.
(In reply to comment #91) > Did anybody even try that patch? Did you have problems with that patch? Comments 50 and 52 through 54 indicate no problems with said patch, no. I for one did not have any problems with it either; from what I can see, it works flawlessly. Personally, I wouldn't mind either way, although I do understand that comment 49 provides a better way of resolving this issue than creating symlinks, much as you stated. > As to why there is no fix in the portage tree: > As was mentioned in Bug 348991: SpanKY has a lot of other stuff to do to > which is obviously of higher priority. He's so busy, he can't even respond > here. Reading through bug 348991 I'm not going to get caught in the middle of the seemingly ongoing dispute and just acknowledge it. Thanks for the pointer.
Hi there, Only for info and to be able to follow up progress on this bug and maybe help if I can I add my 2 cents comment. I just reinstalled my computer with a fresh Gentoo. bussy-2 ~ # binutils-config -l [1] avr-2.22.90 * [2] i686-pc-linux-gnu-2.21.1 * I also got /usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.x: No such file or directory Cheers
Created attachment 333828 [details, diff] recreation of dynamotwain's patch without version I recreated dynamotwain's patch, but without the binutils version number in the pathname. With this patch installed as /etc/portage/patches/cross-avr/binutils/scriptdir.patch the avr.5x bug is corrected for me.
Created attachment 333830 [details, diff] recreation of dynamotwain's patch without version; for real this time Eh. Missed a line in the previous patch. Use this one.
*** Bug 457196 has been marked as a duplicate of this bug. ***
I was trying to get TinyOS work and encountered the same crtm128.o not found error when it comes to avr toolchain (crossdev -t avr --g 4.1.2). The problem was solved by using the multilib patch for crossdev.
The bug's still there :-( My workaround was to: cd /usr/avr/lib/ ln -s ../../lib64/binutils/avr/2.23.2/ldscripts/ as root.
Mike, or anyone from the toolchain herd, suggestions on how to apply this the best way? I'll go crazy and just bang this with an ugly if $CAT/$PKG == cross-avr/binutils.
(In reply to Doug Goldstein from comment #99) > Mike, or anyone from the toolchain herd, suggestions on how to apply this > the best way? I'll go crazy and just bang this with an ugly if $CAT/$PKG == > cross-avr/binutils. As if only affected avr, you're joking right? Last I tried, at least msp430 was affected too. The way you compile binutils is broken. Let's face it.
I can confirm that the patch presented in comment 94 (same as comment 49, but version-agnostic) fixes the issue.
The bug still exists for me. I have crossdev as of todays emerge and it exhibited this problem. The patch in Comment 95 fixed the issue for me. (Using AVR as the Target)
With crossdev ~20140118, avg-gcc 4.8.2, and avr-libc 1.8.0, I am still able to reproduce the problem. Linking ldscripts to the searched-for location or applying the aforementioned patches both fix the issue on my box.
5.11.2014 confirmed: /usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.xn
I also run into this again and again. Given the history of this bug it is safe to assume there won't be a real solution and this is somehow 'system imminent'? A 'won't fix' can be a valid solution too and at least the user base would know what to deal with. Just saying, please don't get me wrong. Cheers, Stephan
I'm sorry but why is this a 9 year old bug when there's a (imho) reasonable patch available? Does anybody with the ability to commit the fix even look this way?
Created attachment 402016 [details, diff] Patch for binutils-2.24 Patch from comment #95 seems to solve the issue for me, but with some changes needed. I include the patch for the binutils 2.24.
*** Bug 530786 has been marked as a duplicate of this bug. ***
So this bug is about ten years old, still unsolved. I'm running into the same issue after I emerged arduino and crossdev -t avr, just don't clearly see how to get through :( .
yeah, it's sad, really. I come back to this bug from time to time too, whenever I play around with arduino. Just go with the symlink. Works for me every time. You may have to re-create it when your system changes but it's no big deal. see comment #14 HTH, Stephan
(In reply to Stephan Menzel from comment #110) > yeah, it's sad, really. > I come back to this bug from time to time too, whenever I play around with > arduino. > Just go with the symlink. Works for me every time. You may have to re-create > it when your system changes but it's no big deal. > > see comment #14 > > HTH, > Stephan Symlinking sounds reasonable enough. Out of curiosity, how does one apply dynamotwain's patch (later refined in comment #95, of course)? Is it to be applied to crossdev-binutils or the mainstream binutils?
Afterthought: isn't `eselect binutils` precisely supposed to manage those symlinks? It doesn't work on my machine but I wanted to be sure I got it right. Or not.
Possibly. I wouldn't know but it sure sounds like it. But not for cross compile I suppose. Anyway, I really don't know much about this bug or why it's never gonna be fixed. All I know is how I worked around it and wanted to let you know. :-) Cheers...
(In reply to Stephan Menzel from comment #113) > Possibly. > I wouldn't know but it sure sounds like it. But not for cross compile I > suppose. Anyway, I really don't know much about this bug or why it's never > gonna be fixed. All I know is how I worked around it and wanted to let you > know. :-) > > Cheers... Well, thanks for it worked indeed. Still curious though.
Why is this bug still unfixed? Does anyone know why?
It's just that nobody cares. This bug is more than 10 years old. Only few people have the knowledge to fix that, unfortunately.
Time does indeed fly. 10 years! Interesting though, how the circumstances around the problem have been stable enough to prevent the bug from being accidentally solved by some other changes or by dependencies being obsolete and replaced or by arduino using a completely different build system. I would expect a bug like this to not be able to live that long even if you actively tried to keep it alive. I mean, if say, my email client has a bug that isn't addressed, what are the odds I still have the same email client 11 years later?
I think it also comes down to comments like comment 91, who I believe was listed as the assignee at the time. As much as I've submitted patches in the past, I don't have the knowledge of the tools available in portage for a proper fix that would cover all of the platforms. I still have the original micro's, as well as a few more of different kinds. Granted what has bee posted in the past is said to just be a workaround, but hey, it works.
We should hold a 10-year reunion for our bug! We could all start a fresh chroot of Gentoo, install avr toolchain, try to compile our microcontroller projects, attempt to use the binutils patch, then give up and use the symlink then come back here and post "symlink patch works for me".
symlink patch works for me
Was this change supposed to workaround the failure? https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=8f04ee910e38c38f597ebebc35190140e6ffa310 I see the change as slightly problematic for the following reasons: - it installs a symlink with crossdev tool and not with binutils (or binutils-config) ebuild itself. crossdev should really be very thin wrapper around emerge. This masks a bug in ebuilds and forces others to rediscover the hack - it installs files both inside /usr/${CTARGET} and outside. Ideally gcc and binutils ebuilds should never do that. (to allow cross-build gcc and binutils among other things) I think proper location for this link is /usr/libexec/gcc/${CTARGET} (with rest of relative paths) which is manager by binutils-config. I'll try to tweak it if nobody objects.
Just to state I don't think the bug should be considered resolved if a workaround is implemented in crossdev. Seems clear that it's under the jurisdiction of the binutils ebuild. Also, cross-toolchains can be installed without crossdev.
It would be very thankful if you solve this problem. :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b023986de7d466d361798bae98f45f8ba7a42e8a commit b023986de7d466d361798bae98f45f8ba7a42e8a Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-04-07 10:40:14 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-07 10:42:41 +0000 sys-devel/binutils: fix ldscrips ${CTARGET} search path, bug #147155 This change fixes long-standing search path issue in Gentoo's binutils: Before the change search path was the following: /usr/${CTARGET}/lib/ldscripts Note: it points to $SYSROOT, not to native cross-tools. After the change search path is the following: /usr/${CHOST}/${CTARGET}/lib/ldscripts Added two notes to the ebuild on how things are supposed to work: - Note [slotting support] - Note [tooldir hack for ldscripts] Applied change to 2.30-r1 and live ebuilds. Reported-by: Heiko Rosemann Closes: https://bugs.gentoo.org/147155 Package-Manager: Portage-2.3.28, Repoman-2.3.9 sys-devel/binutils/binutils-2.30-r1.ebuild | 415 +++++++++++++++++++++++++++++ sys-devel/binutils/binutils-9999.ebuild | 36 ++- 2 files changed, 448 insertions(+), 3 deletions(-)
I think I've finally nailed it down (pushed to binutils-2.30-r1 and -9999). The bug was not in ldscripts symlink placement. Symlink was already fine in /usr/${CHOST}/${CTARGET}/lib/ldscripts but in binutils' ${CTARGET}-ld binary which embedded wrong /usr/${CTARGET}/lib/ldscripts path.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=cb22827620f16f8e29fdeb3654a7e5a846af517e commit cb22827620f16f8e29fdeb3654a7e5a846af517e Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-04-07 10:51:11 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-07 10:51:11 +0000 crossdev: revert ldscripts hack Commit 03640757f2af1471324fc3e305f899f377d6409d ("add one more avr-specific hack") added ${EPREFIX}/usr/${CTARGET}/lib/ldscripts symlink for avr targets. The bug was not avr-specific but manifested only on avr ecause it's one of rare targets that don't embed default inker scripts intofinal ld executable. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b023986de7d466d361798bae98f45f8ba7a42e8a fixed search path in binutils ebuild and we are safe to revert this change. Bug: https://bugs.gentoo.org/147155 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> crossdev | 12 ------------ 1 file changed, 12 deletions(-)}
Thanks (tested OK here)! Note: what looks like the original symptom would happen if for whatever reason, a user has CHOST unset; is_cross() is OK but some things would go in /usr//avr.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=79e2aaafe727f09b7b6a34164a8e88bad6afcdd0 commit 79e2aaafe727f09b7b6a34164a8e88bad6afcdd0 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-04-10 07:51:54 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-04-10 07:51:54 +0000 sys-devel/crossdev: bump up to 20180410 Closes: https://bugs.gentoo.org/652724 Bug: https://bugs.gentoo.org/147155 Bug: https://bugs.gentoo.org/650100 Package-Manager: Portage-2.3.28, Repoman-2.3.9 sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20180410.ebuild | 39 +++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+)}
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ea456d072e46530ea53f04fe8935693fab59093 commit 8ea456d072e46530ea53f04fe8935693fab59093 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2022-06-12 19:43:40 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2022-06-12 19:46:30 +0000 sys-devel/binutils: Prevent relinking on install, try 1 The tooldir hack introduced to solve bug 147155 makes libtool relink libraries during the installation phase. This fails in enough cases to be an annoyance. Use the hack only for cross installations. *Untested*, needs some careful observation before regaining keywords. Bug: https://bugs.gentoo.org/147155 Bug: https://bugs.gentoo.org/834720 Bug: https://bugs.gentoo.org/838925 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-devel/binutils/binutils-2.37_p1-r3.ebuild | 476 +++++++++++++++++++++++++ sys-devel/binutils/binutils-2.38-r3.ebuild | 484 ++++++++++++++++++++++++++ sys-devel/binutils/binutils-9999.ebuild | 21 +- 3 files changed, 978 insertions(+), 3 deletions(-)
