The versions of avr-gcc in linux repositories mostly do not work. I've been trying to build avr-gcc from sources, using scripts provided by Bingo600. So far the effort has not succeeeded. See here http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42... and here http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=12... for some of what has gone before.
I ran ./buildavr-toolchain.sh 2>&1 | tee buildavr-toolchain.out from /home/hennebry/data/projects/avr/gcc/build-avr-gcc-4.5.1-binutils-2.20.1-libc-1.8.0-gdb-7.3.1-dude-5.11.1-avarice-2.12-aw/make-avr-gcc The following is a section of the result:
checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (ld) supports shared libraries... /usr/local/avr/source/gcc-4.5.1/mpc/configure: line 8413: : supported targets:.* elf: command not found no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes checking for ANSI C header files... (cached) no checking complex.h usability... yes checking complex.h presence... no configure: WARNING: complex.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: complex.h: proceeding with the compiler's result checking for complex.h... yes checking locale.h usability... yes
gcc -static doesn't work? libtool doesn't support shared libraries? complex.h? Wow. I did find this: http://www.mail-archive.com/autoconf@gnu.org/msg09268.html , but I don't know what to do about it.
Eventually the script crashes, complaining about the absence of build/genmodes .h .
echo timestamp > s-options gawk -f ../../../source/gcc-4.5.1/gcc/opt-functions.awk -f ../../../source/gcc-4.5.1/gcc/opth-gen.awk \ < optionlist > tmp-options.h /bin/sh ../../../source/gcc-4.5.1/gcc/../move-if-change tmp-options.h options.h echo timestamp > s-options-h TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/sh ../../../source/gcc-4.5.1/gcc/mkconfig.sh bconfig.h gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../source/gcc-4.5.1/gcc -I../../../source/gcc-4.5.1/gcc/build -I../../../source/gcc-4.5.1/gcc/../include -I../../../source/gcc-4.5.1/gcc/../libcpp/include -I/usr/local/avr/source/gcc-4.5.1/gmp -I/usr/local/avr/build/gcc-4.5.1/./mpfr -I/usr/local/avr/source/gcc-4.5.1/mpfr -I/usr/local/avr/source/gcc-4.5.1/mpc/src -I../../../source/gcc-4.5.1/gcc/../libdecnumber -I../../../source/gcc-4.5.1/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/include/libelf \ -o build/errors.o ../../../source/gcc-4.5.1/gcc/errors.c build/genmodes -h > tmp-modes.h /bin/sh: build/genmodes: No such file or directory make[2]: *** [s-modes-h] Error 127 make[2]: Leaving directory `/usr/local/avr/build/gcc-4.5.1/gcc' make[1]: *** [install-gcc] Error 2 make[1]: Leaving directory `/usr/local/avr/build/gcc-4.5.1' make: *** [install] Error 2 (./buildavr-toolchain.sh)GCCC build failed
The last line also contained control characters that didn't cut and paste very well.
I'm told that this output is a symptom of running the script from inside the build directory. Since I didn't do that, there must be another explanation.
Any ideas?
-- Michael hennebry@web.cs.ndsu.NoDak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily
On Mon, 26 Nov 2012, John R Pierce wrote:
On 11/26/12 3:35 PM, Michael Hennebry wrote:
The versions of avr-gcc in linux repositories mostly do not work.
really? the avr-gcc-4.5.x in EPEL for instance?
So far as I am aware, only debian and its package-compatible relatives have an avr-gcc package that works. It was made from the same sources and patches used by Bingo. The off-the-shelf version fron the GNU guys does not work. What was the EPEL version made from?
On 11/26/12 4:46 PM, Michael Hennebry wrote:
On Mon, 26 Nov 2012, John R Pierce wrote:
On 11/26/12 3:35 PM, Michael Hennebry wrote:
The versions of avr-gcc in linux repositories mostly do not work.
really? the avr-gcc-4.5.x in EPEL for instance?
So far as I am aware, only debian and its package-compatible relatives have an avr-gcc package that works. It was made from the same sources and patches used by Bingo. The off-the-shelf version fron the GNU guys does not work. What was the EPEL version made from?
all I know is what this says here...
http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/avr-gcc.html http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/avr-libc.html
saying "does not work" is not very helpful. WHAT doesn't work? surely the compiler compiles code and generates an AVR executable, is there some specific feature or something thats missing? that I can't tell you.
On Mon, 26 Nov 2012, John R Pierce wrote:
On 11/26/12 4:46 PM, Michael Hennebry wrote:
On Mon, 26 Nov 2012, John R Pierce wrote:
On 11/26/12 3:35 PM, Michael Hennebry wrote:
The versions of avr-gcc in linux repositories mostly do not work.
really? the avr-gcc-4.5.x in EPEL for instance?
So far as I am aware, only debian and its package-compatible relatives have an avr-gcc package that works. It was made from the same sources and patches used by Bingo. The off-the-shelf version fron the GNU guys does not work. What was the EPEL version made from?
all I know is what this says here...
http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/avr-gcc.html http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/avr-libc.html
saying "does not work" is not very helpful. WHAT doesn't work? surely the compiler compiles code and generates an AVR executable, is there some specific feature or something thats missing? that I can't tell you.
Apparently the generated code is not correct.
Every so often someone is told to avoid distro versions of avr-gcc, e.g., at http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=99... Clawson wrote:
You are very unwise to use repo versions of avr-gcc as the maintainers don't seem skilled enough to know which are the important patches to be applied when they build.
Far better to get the results of Bingo's build scripts that are hosted on my website here:
www.wrightflyer.co.uk/avr-gcc/
On 11/26/12 6:19 PM, Michael Hennebry wrote:
Far better to get the results of Bingo's build scripts that are hosted on my website here:
www.wrightflyer.co.uk/avr-gcc/
that hasn't been updated in a year, and at the bottom references http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx for the current version...
the release notes say that works on RHEL4/5, Fedora 12 or 13, Suse 11.2,11.3, Ubutntu various... and that it may well work with others. it probably works with CentOS6.
*Clawson* wrote:
You are very unwise to use repo versions of avr-gcc as the maintainers
don't seem skilled enough to know which are the important patches to be applied when they build.
Far better to get the results of Bingo's build scripts that are hosted on
my website here:
www.wrightflyer.co.uk/avr-gcc/
On Mon, 26 Nov 2012, John R Pierce wrote:
that hasn't been updated in a year, and at the bottom references http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx for the current version...
So far as I can tell, neither derives from the other.
the release notes say that works on RHEL4/5, Fedora 12 or 13, Suse 11.2,11.3, Ubutntu various... and that it may well work with others. it probably works with CentOS6.
And I'll probably end up using it. At the moment, I'm waiting for the e-mail that Atmel's registration system supposedly sent me.
That said, 'twould be nice to have a clue what went wrong with the Bingo script.
'Twould be nice just to know what the messages mean. I get the impression that output like this are indications of a problem that is not specific to the particular software that I was trying to compile: autoconf wrote:
checking for stdint.h... (cached) yes checking limits.h usability... yes checking limits.h presence... no configure: WARNING: limits.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: limits.h: proceeding with the compiler's result checking for limits.h... yes checking for unistd.h... (cached) yes checking sys/time.h usability... yes
limits.h: usable, not present, accepted by the compiler, rejected by the preprocessor.
Huh?
Michael Hennebry wrote: <snip>
'Twould be nice just to know what the messages mean. I get the impression that output like this are indications of a problem that is not specific to the particular software that I was trying to compile: autoconf wrote:
checking for stdint.h... (cached) yes checking limits.h usability... yes checking limits.h presence... no configure: WARNING: limits.h: accepted by the compiler, rejected by the preprocessor! configure: WARNING: limits.h: proceeding with the compiler's result checking for limits.h... yes checking for unistd.h... (cached) yes checking sys/time.h usability... yes
limits.h: usable, not present, accepted by the compiler, rejected by the preprocessor.
Huh?
Here's a question: *which* limits.h? On my 6.3 system, if I locate limits.h, I get: /usr/include/limits.h /usr/include/c++/4.4.4/tr1/limits.h /usr/include/linux/limits.h /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/limits.h /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/syslimits.h /usr/share/doc/pam-1.1.1/html/sag-pam_limits.html /usr/share/man/man0p/limits.h.0p.gz /usr/src/kernels/2.6.32-279.1.1.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.11.1.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.2.1.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.5.2.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.9.1.el6.x86_64/include/linux/limits.h
-- Michael hennebry@web.cs.ndsu.NoDak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily
*sigh* And she didn't have a shield? What *were* they thinking?
mark "my old shield's in the family room...."
On Tue, 27 Nov 2012, m.roth@5-cent.us wrote:
Michael Hennebry wrote:
<snip> > 'Twould be nice just to know what the messages mean. > I get the impression that output like this are indications of a problem > that > is not specific to the particular software that I was trying to compile: > autoconf wrote: >> checking for stdint.h... (cached) yes >> checking limits.h usability... yes >> checking limits.h presence... no >> configure: WARNING: limits.h: accepted by the compiler, rejected by the >> preprocessor! >> configure: WARNING: limits.h: proceeding with the compiler's result >> checking for limits.h... yes >> checking for unistd.h... (cached) yes >> checking sys/time.h usability... yes > > limits.h: > usable, not present, accepted by the compiler, rejected by the > preprocessor. > > Huh?
Here's a question: *which* limits.h? On my 6.3 system, if I locate limits.h, I get: /usr/include/limits.h /usr/include/c++/4.4.4/tr1/limits.h /usr/include/linux/limits.h /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/limits.h /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/syslimits.h /usr/share/doc/pam-1.1.1/html/sag-pam_limits.html /usr/share/man/man0p/limits.h.0p.gz /usr/src/kernels/2.6.32-279.1.1.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.11.1.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.2.1.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.5.2.el6.x86_64/include/linux/limits.h /usr/src/kernels/2.6.32-279.9.1.el6.x86_64/include/linux/limits.h
Don't know for sure. I have even more.
From experiment, gcc and cpp search the same directories:
/usr/local/include /usr/lib/gcc/i686-redhat-linux/4.4.6/include /usr/include
/usr/local/include does not have a limits.h . /usr/lib/gcc/i686-redhat-linux/4.4.6/include/limits.h has a #include_next <limits.h> that grabs /usr/include/limits.h .
On 11/27/12 8:31 AM, Michael Hennebry wrote:
That said, 'twould be nice to have a clue what went wrong with the Bingo script.
it was written for a specific ubuntu/debian flavor and not tested elsewhere. autoconf is a gnarly thing, the scripts for it need to be carefully developed, just because what you do with it works on a single platform does NOT automatically mean it will work on all platforms.
its possible you're missing one or more -devel packages for something it needs. its possible its looking for stuff in debian specific locations and on EL they are somewhere else. its possible it depends on some specific version of a system library or developer tool or whatever and EL5/6 uses a different version.
I note there's a source package on that AVR site, it might be worth trying to build from there. optimally, get that to build, then package it as an RPM, and get it into one of the more popular repositories, and all that 'repos are bad' nonsense goes away.
On Tue, 27 Nov 2012, John R Pierce wrote:
On 11/27/12 8:31 AM, Michael Hennebry wrote:
That said, 'twould be nice to have a clue what went wrong with the Bingo script.
it was written for a specific ubuntu/debian flavor and not tested elsewhere. autoconf is a gnarly thing, the scripts for it need to be carefully developed, just because what you do with it works on a single platform does NOT automatically mean it will work on all platforms.
I'd thought that was the point of autoconf.
I note there's a source package on that AVR site, it might be worth trying to build from there. optimally, get that to build, then package it as an RPM, and get it into one of the more popular repositories, and all that 'repos are bad' nonsense goes away.
Maybe later, much later. I've never built an RPM. The only real compiler I've built is avr-gcc from the Bingo scripts. I've battled autoconf-generated scripts before and lost every time. That said, I have managed to build X from source. I just followed directions and voila, there it was. I did look at its build system. It was a horror. Had it not worked perfectly, I would have been out of luck.
Michael Hennebry wrote:
On Tue, 27 Nov 2012, John R Pierce wrote:
On 11/27/12 8:31 AM, Michael Hennebry wrote:
That said, 'twould be nice to have a clue what went wrong with the Bingo script.
it was written for a specific ubuntu/debian flavor and not tested elsewhere. autoconf is a gnarly thing, the scripts for it need to be carefully developed, just because what you do with it works on a single platform does NOT automatically mean it will work on all platforms.
I'd thought that was the point of autoconf.
<snip>
Maybe later, much later. I've never built an RPM. The only real compiler I've built is avr-gcc from the Bingo scripts. I've battled autoconf-generated scripts before and lost every time. That said, I have managed to build X from source. I just followed directions and voila, there it was. I did look at its build system. It was a horror. Had it not worked perfectly, I would have been out of luck.
A suggestion: look at configure. specifically at the options it allows that might be specific to this package. See if there's something that lets you choose the source directory for limits.h. I've managed to beat autoconf to do what I wanted a few times following that route.
mark
-
John R Pierce -
m.roth＠5-cent.us -
Michael Hennebry