"emerge dev-embedded/avr-libc" fails complaining: checking for suffix of object files... configure: error: in `/var/tmp/portage/dev-embedded/avr-libc-1.8.0/work/avr-libc-1.8.0': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details Running "./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=avr --target=avr --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-dependency-tracking" manually in the ebuild work dir works. The error only happens when configure is run from the ebuild environment. Reproducible: Always
Created attachment 298883 [details] config.log from failed emerge
Created attachment 298885 [details] failed build log
Created attachment 298889 [details] environment from failed emerge
Created attachment 298891 [details] config.log from succsesful manual run with the same options
I can confirm that I have exactly the same issue. This appears to be the -m64 compiler directive from the amd64 portage environment getting to the avr compiler. Unsurprisingly the avr compiler is very confused by this. I get the same error on previous versions (1.7.0, 1.7.1) which have previously built correctly. It therefore seems to be due to a change in portage, not the avr-libc package. the avr-libc package merges correctly on an x86 machine - which doesn't have the -m64 directive, and I can build manually from the portage compilation directory on the amd64 machine which has the problem.
Created attachment 299549 [details] avr-libc-1.8.0-r1.ebuild When ABI is set to amd64 portage will unconditionally append -m64 to CFLAGS, which avr-gcc doesn't recognize as a valid option. Solve the problem by setting ABI=avr in the ebuild. I pushed the updated ebuild to git://gitorious.org/~luksan/gentoo-arduino/luksans-arduino.git
Thanks very much, that works very well for me, the package now merges correctly and a couple of trial avr compiles were OK :-) I don't know enough about the internals of portage (or gcc come to that) to have fixed it despite some trawling over the last couple of weeks. Hopefully this is clear enough to get fixed by the package maintainer...
`crossdev avr` would set up your env correctly