Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 147155 - cross-avr/binutils - "ld" for avr cannot find linker script "avr5.x"
Summary: cross-avr/binutils - "ld" for avr cannot find linker script "avr5.x"
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major with 39 votes (vote)
Assignee: Gentoo Crossdev team
URL:
Whiteboard:
Keywords:
: 179824 203859 280148 340114 457196 530786 (view as bug list)
Depends on:
Blocks: 348991 crossdev-bugs
  Show dependency tree
 
Reported: 2006-09-11 02:50 UTC by Heiko Rosemann
Modified: 2022-06-14 02:39 UTC (History)
78 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
The Makefile causing the error (Makefile,11.07 KB, text/plain)
2006-09-11 02:51 UTC, Heiko Rosemann
Details
Example c-Code - can be used to re-create the bug (main.c,225 bytes, text/plain)
2006-09-11 02:52 UTC, Heiko Rosemann
Details
Sorry, this one is the failing Makefile... (Makefile,11.07 KB, text/plain)
2006-09-11 02:55 UTC, Heiko Rosemann
Details
This is the "crashing" strace log - created with -mmcu=atmega32 (strace.avr5,40.43 KB, text/plain)
2007-05-17 21:39 UTC, Heiko Rosemann
Details
This is the "working" strace log - created with -mmcu=at90s8535 (strace.avr4,45.85 KB, text/plain)
2007-05-17 21:41 UTC, Heiko Rosemann
Details
strace log (LOG,23.00 KB, text/plain)
2007-10-21 14:13 UTC, Denilson Sá Maia
Details
output of "avr-gcc -v -mmcu=atmega128 test.c" (avr-gcc-out.txt,2.66 KB, text/plain)
2009-10-25 13:11 UTC, Sven
Details
strace of "avr-gcc-strace.txt avr-gcc -mmcu=atmega128 test.c" (avr-gcc-strace.txt,42.83 KB, text/plain)
2009-10-25 13:12 UTC, Sven
Details
strace of "avr-ld -m avr5" (avr-ld-strace.txt,13.10 KB, text/plain)
2009-10-25 13:21 UTC, Sven
Details
change ld's $(scriptdir) to the actual path where the ldscripts will be installed (binutils-2.20.1-scriptsdir.patch,954 bytes, patch)
2010-08-15 06:45 UTC, dynamotwain
Details | Diff
Log of commands+crossdev build (consolelog-090511.txt,5.01 KB, text/plain)
2011-09-05 14:23 UTC, Brandon Penglase
Details
Crossdev AVR Multilib Patch (Updated) (avr-multilib.patch,972 bytes, patch)
2012-04-15 04:09 UTC, Brandon Penglase
Details | Diff
Creates ldscripts symlink on AVR target (avr-ldscripts-symlink.patch,930 bytes, patch)
2012-04-15 17:16 UTC, Brandon Penglase
Details | Diff
EBuild that applies the patches to crossdev (crossdev-20120305-r1.ebuild,1.04 KB, text/plain)
2012-04-15 17:25 UTC, Brandon Penglase
Details
recreation of dynamotwain's patch without version (scriptdir.patch,812 bytes, patch)
2012-12-31 05:55 UTC, Drake Wyrm
Details | Diff
recreation of dynamotwain's patch without version; for real this time (scriptdir.patch,736 bytes, patch)
2012-12-31 06:01 UTC, Drake Wyrm
Details | Diff
Patch for binutils-2.24 (file_147155.txt,391 bytes, patch)
2015-04-25 22:08 UTC, Paweł Stankowski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Rosemann 2006-09-11 02:50:43 UTC
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
Comment 1 Heiko Rosemann 2006-09-11 02:51:38 UTC
Created attachment 96679 [details]
The Makefile causing the error
Comment 2 Heiko Rosemann 2006-09-11 02:52:18 UTC
Created attachment 96680 [details]
Example c-Code - can be used to re-create the bug
Comment 3 Heiko Rosemann 2006-09-11 02:55:29 UTC
Created attachment 96681 [details]
Sorry, this one is the failing Makefile...

...the other one has the different MCU-type selection...
Comment 4 Tim Boundy 2006-09-14 04:50:38 UTC
# 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
Comment 5 SpanKY gentoo-dev 2006-09-17 00:25:04 UTC
fixed with binutils-config-1.9-r2 ... symlinked ldscripts into the gcc libexec path
Comment 6 Heiko Rosemann 2007-05-12 22:27:55 UTC
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
Comment 7 Denis Dupeyron (RETIRED) gentoo-dev 2007-05-13 16:32:44 UTC
(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.
Comment 8 SpanKY gentoo-dev 2007-05-15 01:05:14 UTC
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
Comment 9 Heiko Rosemann 2007-05-17 21:34:46 UTC
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
Comment 10 Heiko Rosemann 2007-05-17 21:39:45 UTC
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
Comment 11 Heiko Rosemann 2007-05-17 21:41:29 UTC
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
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2007-05-26 07:10:12 UTC
*** Bug 179824 has been marked as a duplicate of this bug. ***
Comment 13 Jakub Moc (RETIRED) gentoo-dev 2007-05-26 07:11:13 UTC
Reopen wrt Bug 179824.
Comment 14 whereami 2007-05-27 04:47:56 UTC
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
Comment 15 whereami 2007-05-27 04:57:12 UTC
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.
Comment 16 Lars Weiler (RETIRED) gentoo-dev 2007-06-11 13:05:45 UTC
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.
Comment 17 christian.roeder 2007-09-28 21:20:13 UTC
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.
Comment 18 Denilson Sá Maia 2007-10-21 14:12:22 UTC
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.
Comment 19 Denilson Sá Maia 2007-10-21 14:13:57 UTC
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
Comment 20 Denilson Sá Maia 2007-10-21 14:15:55 UTC
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
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2007-12-31 09:03:12 UTC
*** Bug 203859 has been marked as a duplicate of this bug. ***
Comment 22 Niklas Johansson 2008-02-19 14:56:50 UTC
(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/"



Comment 23 Niklas Johansson 2008-02-21 17:37:04 UTC
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
           
Comment 24 Denilson Sá Maia 2008-02-21 20:25:42 UTC
(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.
Comment 25 bb 2008-11-02 20:41:42 UTC
(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
Comment 26 Sven 2008-11-24 14:53:29 UTC
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?
Comment 27 Keith Amidon 2008-12-24 05:55:09 UTC
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?
Comment 28 Keith Amidon 2009-01-03 19:19:35 UTC
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.
Comment 29 Keith Amidon 2009-01-03 19:31:11 UTC
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.
Comment 30 Aurélien Francillon 2009-01-04 12:48:11 UTC
(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

Comment 31 Nicholas Vinen 2009-03-02 22:42:41 UTC
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.
Comment 32 Nicholas Vinen 2009-03-02 22:46:09 UTC
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
Comment 33 Thomas Capricelli 2009-08-04 11:08:22 UTC
*** Bug 280148 has been marked as a duplicate of this bug. ***
Comment 34 Thomas Capricelli 2009-08-04 11:24:43 UTC
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...
Comment 35 regomodo 2009-08-11 13:59:08 UTC
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
Comment 36 Thomas Capricelli 2009-08-11 14:12:03 UTC
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.
Comment 37 Sven 2009-10-25 13:10:06 UTC
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.
Comment 38 Sven 2009-10-25 13:11:52 UTC
Created attachment 208206 [details]
output of "avr-gcc -v -mmcu=atmega128 test.c"
Comment 39 Sven 2009-10-25 13:12:24 UTC
Created attachment 208208 [details]
strace of "avr-gcc-strace.txt avr-gcc -mmcu=atmega128 test.c"
Comment 40 Sven 2009-10-25 13:21:02 UTC
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.
Comment 41 Kameron Larsen 2009-11-19 03:04:14 UTC
(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!
Comment 42 Maksym Sditanov 2009-12-08 20:24:49 UTC
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
Comment 43 Michael Conrad 2010-03-15 22:14:46 UTC
(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.
Comment 44 Thomas Capricelli 2010-04-06 00:19:28 UTC
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
Comment 45 Thomas Capricelli 2010-04-06 00:28:51 UTC
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)
Comment 46 Diego Stamigni 2010-05-21 23:42:30 UTC
(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.
Comment 47 Joaquin Ignacio Bogado Garcia 2010-06-09 23:12:13 UTC
(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.
Comment 48 Piotr 2010-07-08 14:56:24 UTC
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?
Comment 49 dynamotwain 2010-08-15 06:45:09 UTC
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.
Comment 50 Carlos Silva 2010-09-03 20:48:04 UTC
Looks like a patch is in place. Please fix this so we can have a sane environment.
Comment 51 SpanKY gentoo-dev 2010-10-08 09:48:21 UTC
*** Bug 340114 has been marked as a duplicate of this bug. ***
Comment 52 Sven 2010-10-08 11:38:12 UTC
Soon, this bug will be 4 years old.
@maintainer: please do something about it!

The solutions provided in comment #49 looks fine to me.
Comment 53 Alexander Holler 2010-10-22 23:01:14 UTC
I can confirm that the patch from comment #49 works without any problems.
Comment 54 Thomas, Berlinghoff 2010-11-30 22:22:17 UTC
Patch from comment #49 works for me too.
Comment 55 Enrico Tagliavini 2010-12-16 10:54:29 UTC
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.
Comment 56 Sven 2010-12-16 12:12:20 UTC
binutils 2.21 still fails:
$ avr-ld -mavr5
avr-ld: cannot open linker script file ldscripts/avr5.x: No such file or directory
Comment 57 Samuli Suominen (RETIRED) gentoo-dev 2010-12-18 06:21:09 UTC
*** Bug 348991 has been marked as a duplicate of this bug. ***
Comment 58 Jeroen Roovers (RETIRED) gentoo-dev 2010-12-18 18:42:05 UTC
*** Bug 348991 has been marked as a duplicate of this bug. ***
Comment 59 SpanKY gentoo-dev 2010-12-18 22:51:34 UTC
*** Bug 348991 has been marked as a duplicate of this bug. ***
Comment 60 Thomas, Berlinghoff 2011-01-09 02:50:17 UTC
(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.
Comment 61 Ivan Asmer 2011-01-13 17:37:31 UTC
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
Comment 62 Brandon Penglase 2011-07-12 00:51:57 UTC
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
Comment 63 Pascal de Bruijn 2011-07-17 11:49:45 UTC
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.
Comment 64 Michael Moon 2011-07-30 09:50:01 UTC
This affects me too.
Comment 65 Aydin Tarik Zengin 2011-08-04 08:24:05 UTC
Same here for Arduino Mega2560,

/usr/libexec/gcc/avr/ld: crtm2560.o: No such file: No such file or directory
Comment 66 Andrew Walker 2011-08-16 13:39:26 UTC
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.
Comment 67 Ilya Dmitrichenko 2011-09-04 18:01:54 UTC
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.
Comment 68 Ilya Dmitrichenko 2011-09-04 21:14:31 UTC
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.
Comment 69 Ilya Dmitrichenko 2011-09-04 22:07:08 UTC
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 :))
Comment 70 Sven 2011-09-04 23:03:44 UTC
(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.
Comment 71 Brandon Penglase 2011-09-05 01:59:43 UTC
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.
Comment 72 Ilya Dmitrichenko 2011-09-05 06:55:07 UTC
> 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.
Comment 73 Brandon Penglase 2011-09-05 14:23:40 UTC
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.
Comment 74 Brandon Penglase 2011-09-05 15:37:33 UTC
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.
Comment 75 David Relson 2011-12-27 00:59:35 UTC
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
Comment 76 David Relson 2011-12-27 04:32:32 UTC
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
Comment 77 Ilya Dmitrichenko 2012-01-03 13:30:33 UTC
(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).
Comment 78 Niklas Johansson 2012-02-05 19:13:06 UTC
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?
Comment 79 Niklas Johansson 2012-02-05 21:16:18 UTC
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
Comment 80 Niklas Johansson 2012-02-05 21:17:13 UTC
(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"
Comment 81 Niklas Johansson 2012-02-05 21:21:05 UTC
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*)
Comment 82 Niklas Johansson 2012-02-05 22:10:59 UTC
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.
Comment 83 Christian Ruppert (idl0r) gentoo-dev 2012-04-14 02:58:19 UTC
I thought that was already fixed but apparently it's not :(
Is there any progress on this bug?
Comment 84 Thomas Capricelli 2012-04-14 18:49:24 UTC
no :-(
Comment 85 Brandon Penglase 2012-04-15 04:09:51 UTC
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 :)
Comment 86 Brandon Penglase 2012-04-15 17:16:40 UTC
Created attachment 309069 [details, diff]
Creates ldscripts symlink on AVR target
Comment 87 Brandon Penglase 2012-04-15 17:25:52 UTC
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.
Comment 88 Michael Weber (RETIRED) gentoo-dev 2012-04-24 01:26:52 UTC
(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.
Comment 89 Brandon Penglase 2012-06-09 03:08:16 UTC
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.
Comment 90 shinydoofy 2012-07-13 19:46:58 UTC
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?
Comment 91 Sven 2012-07-13 20:08:14 UTC
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.
Comment 92 shinydoofy 2012-07-14 01:20:37 UTC
(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.
Comment 93 Jean-Marc Beaune 2012-08-05 10:42:52 UTC
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
Comment 94 Drake Wyrm 2012-12-31 05:55:09 UTC
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.
Comment 95 Drake Wyrm 2012-12-31 06:01:06 UTC
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.
Comment 96 Jeroen Roovers (RETIRED) gentoo-dev 2013-02-14 14:20:51 UTC
*** Bug 457196 has been marked as a duplicate of this bug. ***
Comment 97 Steven Lai 2013-06-11 02:20:52 UTC
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.
Comment 98 Łukasz Stelmach 2013-12-28 10:57:22 UTC
The bug's still there :-( My workaround was to:

cd /usr/avr/lib/
ln -s ../../lib64/binutils/avr/2.23.2/ldscripts/

as root.
Comment 99 Doug Goldstein (RETIRED) gentoo-dev 2014-03-15 01:04:32 UTC
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.
Comment 100 Sven 2014-03-15 10:47:17 UTC
(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.
Comment 101 Taahir Ahmed 2014-03-19 02:19:53 UTC
I can confirm that the patch presented in comment 94 (same as comment 49, but version-agnostic) fixes the issue.
Comment 102 StevenJ 2014-03-19 09:34:26 UTC
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)
Comment 103 Ben Chociej 2014-08-27 03:07:23 UTC
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.
Comment 104 karpi 2014-11-05 21:32:27 UTC
5.11.2014 confirmed:
/usr/libexec/gcc/avr/ld: cannot open linker script file ldscripts/avr5.xn
Comment 105 Stephan Menzel 2014-11-05 21:46:53 UTC
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
Comment 106 Ben Klopfenstein 2015-03-05 07:18:04 UTC
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?
Comment 107 Paweł Stankowski 2015-04-25 22:08:12 UTC
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.
Comment 108 SpanKY gentoo-dev 2015-05-26 00:05:27 UTC
*** Bug 530786 has been marked as a duplicate of this bug. ***
Comment 109 Vince C. 2015-12-20 13:36:19 UTC
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 :( .
Comment 110 Stephan Menzel 2015-12-20 14:21:19 UTC
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
Comment 111 Vince C. 2015-12-21 12:10:50 UTC
(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?
Comment 112 Vince C. 2015-12-22 18:19:57 UTC
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.
Comment 113 Stephan Menzel 2015-12-22 18:37:16 UTC
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...
Comment 114 Vince C. 2015-12-24 20:38:43 UTC
(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.
Comment 115 oddman621 2017-06-23 03:36:51 UTC
Why is this bug still unfixed? Does anyone know why?
Comment 116 Thomas Capricelli 2017-06-23 09:40:29 UTC
It's just that nobody cares. This bug is more than 10 years old. Only few people have the knowledge to fix that, unfortunately.
Comment 117 Stephan Menzel 2017-06-23 11:00:36 UTC
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?
Comment 118 Brandon Penglase 2017-06-23 13:13:13 UTC
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.
Comment 119 Michael Conrad 2017-06-26 19:56:29 UTC
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".
Comment 120 Valentin Marinov 2017-10-13 12:33:50 UTC
symlink patch works for me
Comment 121 Sergei Trofimovich (RETIRED) gentoo-dev 2018-04-05 17:58:04 UTC
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.
Comment 122 cJ 2018-04-05 20:58:36 UTC
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.
Comment 123 oddman621 2018-04-06 03:08:09 UTC
It would be very thankful if you solve this problem. :)
Comment 124 Larry the Git Cow gentoo-dev 2018-04-07 10:43:00 UTC
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(-)
Comment 125 Sergei Trofimovich (RETIRED) gentoo-dev 2018-04-07 10:48:23 UTC
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.
Comment 126 Larry the Git Cow gentoo-dev 2018-04-07 10:56:12 UTC
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(-)}
Comment 127 cJ 2018-04-07 16:02:42 UTC
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.
Comment 128 Larry the Git Cow gentoo-dev 2018-04-10 07:52:14 UTC
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(+)}
Comment 132 Larry the Git Cow gentoo-dev 2022-06-12 19:46:41 UTC
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(-)