There is no need for uninstalling the .deb
The deb only install files in /usr/local/avr , and as long as you don't touch anything there , you can leave it installed
Thanks for all the answers.
The key of the mystery was the path. I've supposed the /usr/local/avr/bin path will be added to my path by the script - and even worse, there was that forgotten, partly aborted version of avr toolchain.
Now as I set the path, everything is right. Thanks for the script, Bingo!
Istvan
It took me a while to remember how to do PHP but I've updated the index.php on the website to give some very brief instructions including a note about setting the PATH
It took me a while to remember how to do PHP but I've updated the index.php on the website to give some very brief instructions including a note about setting the PATH
Hi,
I'm using avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb package and I'm trying to program an avr ATXMega256A3. Compiling with avr-gcc and flashing with avrdude works great. I use an MKII Jtag ICE to upload the application on the flash and I'm trying on chip debugging. It looks like on chip debugging is working right as when I hit CTRL+C it stops running and gdb tells me the instruction where the application stopped.
However I can't watch / display variables nor set/delete breakpoints.
Xmega256A3 data is store in SRAM (0x802000 <-> 0x805FFF). when I try to print a variable, and watch avarice debug, I see something like this:
As you can see from the debug information, gdb asks for location (0x800000 + 1) and does not account for the data offset NOR for the fact that data is stored on the ATXMega starting from the higher addresses (0x805FFF) up to the lower ones).
I wonder if it's gdb or avarice responsibility to account for these offsets...
I'd really appreciate your help guys...
Thankx in advance
I'm be waiting for any comment help hint or scolding me..
FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.
For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.
FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.
For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.
The scripts use a dangerous approach of assuming various directory creation and navigation commands work and then executing "rm -fr *" without ensuring that the current directory is what it should be. I had to spend a good chunk of last Sunday restoring from backup after one of the scripts wiped out a large part of my home directory.
Following the scripts and attempting to replicate the build process by hand yields a toolchain that works for tiny26 and mega32 projects, but can not find C runtime files for the xmega32A4:
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: crtx32a4.o: No such file: No such file or directory
This file does exist, it's in /Users/cjh/avr/avr/lib/avrxmega2/crtx32a4.o (prefix is $HOME/avr/). Moving it into the project directory yields different errors with libmath and libc:
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: skipping incompatible /Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/lib/libm.a when searching for -lm
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: cannot find -lm
Omitting -lm yields:
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: skipping incompatible /Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/lib/libc.a when searching for -lc
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: cannot find -lc
And similar for the libraries, but long lists of entries of the same format and architecture "avr".
I'm using Mac OS X 10.6.5. The major differences from the scripts are that I'm using avr-libc-1.7.0, more recent versions of GMP and MPFR, and removing an instance of tree-inline.o from the GCC makefiles to fix a duplicate symbols problem. (bug in Snow Leopard's linker...won't ignore duplicate symbols from static libraries)
You dont write what buildscript-filename , shell-file and line that caused you trouble.
So i'll assume it's this buildscript https://www.avrfreaks.net/index.p... , and the buildavr-cleanup.sh script.
And in the post that the above url refers to : It states
Quote:
When building is done , you might want to free around 500MB of diskspace by removing the sources and binaries used to make avr-gcc.
To do so Run: ./buildavr-cleanup.sh
Note this little script expects the "build prefix" to be /usr/local/avr/
So if it was the cleanup script causing the trouble. The info (warning) was there , and you are the first that i know of , to have been "bitten".
The buildavr-cleanup.sh , was a quick "hack" because some users complained about the finished toolchain being 500MB+
As stated , the script are only tested on Ubuntu.
But a lot of people reports that with minor "adaptation" it also works on other *nixes.
That is the buildscript I used, but it was get-patches.sh that blew away part of my home directory. There's several times that it does mkdir's and cd's without checking for failure, blindly does "cd ..", and it simply experienced a couple failures and climbed up into my home directory before doing another "rm-fr *".
It would be much better to always specify full absolute paths, especially in the rm command. This alone would have prevented the issue, since it would have been trying to rm a nonexistent directory...it would not matter if it were in the wrong directory following a failure. I would also suggest simplifying it to put everything in a fully specified build directory rather than constantly creating and deleting this and that...it would be simpler, clearer, and less fragile.
As for the readme, I strongly suggest reorganizing it. There's no clear starting point for figuring out how to use the scripts, the quoted portion at first glance appearing to be an old portion of the revision history.
Funny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?
Funny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?
It's good you've never had them run amok, because they would have done a lot more damage if you were blindly following those directions. Running the scripts with the root or sudo privileges needed for an install to /usr/local would not have improved matters...it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there. As it was, I noticed it was misbehaving when it started hitting files it didn't have the permissions needed to delete.
And yes, aside from limiting the potential damage from misbehaving scripts, building a standalone toolchain makes it trivially easy to switch between different versions of a toolchain, and keeps all the stuff related to that toolchain in one place. I didn't install to /usr/local because I didn't want it there.
It's clear that there's a major issue with the scripts' assumptions that directory creation and navigation will always succeed, coupled with running a dangerous command without any sanity checks. That you've never had trouble does not change the fact that failures can lead to it blindly deleting everything in higher level directories. Depending on the choice of download locations and how closely the directions are followed, it can delete nearly everything on the hard drive, OS included. Is your response to this really "it always worked for me" followed by questioning my choice of install locations?
it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there
Wouldn't matter to me - I use VM's - if it ever gets corrupted I return to a previous snapshot or recreate it.
Well good for you! Can you at least admit that this might be something of an issue for other people?
It's simple. Potentially crawling up your directory tree and deleting everything in sight without warning is not desired behavior, okay?
Bingo600 wrote:
Well it's always nice with some feedback , even though you are the first i have heard about that has lost control.
And people has been using the scripts for four years now.
With the above mentioned readme et all.
I hope Ruud's script lives up to your expectations.
Edit: I can see it loose control if you are calling the scripts from another location. As it can't source the package-versions file.
Maybe i'll add a check for that.
:shock:
Look. Running the scripts as instructed is potentially equivalent to typing "sudo rm -rf *" in any containing directory, up to and including the root directory of the filesystem. This is a major issue that needs fixing, the scripts in their current state are brittle and fail catastrophically. That you haven't had reports of issues up to now is pure luck. You have now had such a report, and a clear description of what the problem is and why.
There is no reason to clear out unneeded files by attempting to cd to a location and then deleting everything in the current working directory. Simply working out what directory the items to be deleted should be in and passing that to rm will avoid the issue...if the directory doesn't exist, the script won't fail by crawling up the directory tree deleting everything in its path. This doesn't take a huge amount of effort to implement, and doesn't make things harder to maintain or follow...if anything, it makes it clearer what the scripts are doing and easier to ensure that they do only what you want.
If it's so easy for you to do , why don't you submit the modified script here.
Nothing stops you from helping out.
Then maybe i'll get my first patch , along with the first
Quote:
You have now had such a report, and a clear description of what the problem is and why.
Have a nice life , and i'll consider to make it a FLASH guide in my next version.
Posted by hardfricky: Mon. Jan 24, 2011 - 01:39 PM
1
2
3
4
5
Total votes: 0
Hi,
Sorry for the cross-posting. I am trying to make a 1-file-only build script for the last version of the avr-gcc/avr-libc tools, as mentioned here: https://www.avrfreaks.net/index.p...
The script uses the information on Bingo's scripts but is adapted from the scripts used to install the cross-compilers for arm.
I was able to build the version 4.5.1 previously but not sure why I run into some trouble now that I try with 4.5.2. After installation, when I use avr-gcc I get this message:
I know there are packages for ubuntu, but they are broken (again, see my unreplied post at the link above).
I am not able to attach the script file (I think there is a problem with the avrfreaks website, not sure), so here it is: http://www.cl.cam.ac.uk/~osc22/f...
I hope some of you will find it useful (especially if I manage to fix this error).
Nice script ..
But why do you want the latest GCC ? , especially for a target like AVR.
Those patches in my buildscript is actually enabling/fixing a lot of things in the various packages.
I haven't got a good idea for your problem , but was wondering why you have/need these two options on the "configure" --program-prefix=avr- --with-gcc
Posted by hardfricky: Mon. Jan 24, 2011 - 10:17 PM
1
2
3
4
5
Total votes: 0
The 2 parameters are a remainder from the original arm-gcc-cross-compiler building script. However both of them are correct and do not affect in a negative way the building of the tools (feel free to try).
The package for ubuntu, available here: http://www.wrightflyer.co.uk/avr...
is broken as I have mentioned. It did not include the patch for delay.h.in in the avr-libc-1.7.0. One more reason why to have a building script functional that can be easily modified (I find more easy to modify my script than yours, no offence).
Why GCC-4.5.2? Well, I believe is better to go with the latest version, since they generally bring improvements. However, after a little Google (one of my friends suggested I need some practice on this...):
- from http://gcc.gnu.org/gcc-4.5/chang...
- new link-time-optimizer (sounds nice from description)
- automatic parallelisation pass
- optimising exception handling code (probably doesn't apply to our AVR targets, but still nice)
- just C related:
- -Wenum-compare option to warn about different enum types
- Added support for these new AVR devices:
ATmega8U2
ATmega16U2
ATmega32U2
- it is now possible to extend the compiler without having to modify its source code
- from http://gcc.gnu.org/ml/gcc-announ...
- improved loop optimization infrastructure
- GCC 4.5.0 also features improvements for a wide variety of specific
architectures, including support for recent CPUs using the ARM, AVR...
- many more ... (please read the links above).
The wisdom of the libc/avr-gcc maintainers is almost always the better place to start. It takes for fracking ever for anything to actually get released into gcc. And new processors are going to be unstable for a while. The patches that bingo uses which are from the toolchain maintainers mouths are based on the latest and most stable versions for this processor.
Current versions (see the script to be sure):
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"
Bingo if you (and others) find it useful, feel free to add it on the first page.
I suppose it was EW's hints on the avr-gcc list what brought you on track.
Congratulations in writing a very nice buildscript.
It still amazes me though :
That you chose to ignore the warnings in the last posts about using the unpatched upstream avr-gcc.
Instead of the proven 4.3.4 with the current maintainer patches applied.
These patches are created by Eric Weddington (WinAVR) , who adviced you on the "list". And Jörg Wunsch (avr-libc & FreeBSD port of avr-gcc).
And i sincerely hope your students won't be bitten , as these patches most likely haven't gone into the version of GCC that you are using.
Posted by hardfricky: Wed. Jan 26, 2011 - 06:33 PM
1
2
3
4
5
Total votes: 0
Yes, it was EW's hints on the avr-gcc (as well as some other messages on the gcc-help list) that have helped me.
Well, it is not that I choose to ignore, I just want to provide a working script for the last version of GCC for those (like me) that want to use it.
Also, using your scripts, or the maintained 4.3.4 packages give extra work like applying missing patches.
I am sure the 4.3.4 version might be more stable, but why not trying to make it work with the current version?
Regarding the patches you refer to, I think that many patches have gone into the current (4.5.2) GCC version; at least from the Changelogs it seems that some things related to AVR have been aded.
@Omar
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.
Btw: The reason i haven't updated the .deb packages with the new delay.h is that i follow the FreeBSD source like 99.9% , and Jörg hasn't released avr-libc-1.7.1 yet.
But your post actually made me upload the correct delay.h file , and write a warning in the "readme's" on http://www.wrightflyer.co.uk/avr...
Posted by SprinterSB: Thu. Feb 10, 2011 - 04:57 PM
1
2
3
4
5
Total votes: 0
Bingo600 wrote:
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.
Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.
I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.
avrfreaks does not support Opera. Profile inactive.
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.
Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.
I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.
I don't have any examples , but i'm quite sure that it was Eric (EW) mentioning this on one of the mailinglists. As an answer to why patches wasn't moved upstream.
Current versions (see the script to be sure):
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"
Posted by hardfricky: Mon. Feb 14, 2011 - 09:01 PM
1
2
3
4
5
Total votes: 0
Thanks Bingo.
I have added a patch for the bug and I see the bug has now been fixed for GCC 4.6. Also I updated my script to use this patch.
Maybe we can make a complete list of unsolved bugs for 4.5.2 and hope they will all be fixed for release 4.6. And we could try to start converging from there.
Is there a _single_ location available that at least links to all the files necessary to get up-to-date mcus working?
I must have spent have a day compiling (using the script and the manual on the avr-libc site) only to find out that e.g. my newly acquired ATtiny4313 is not supported by the compiled avr-gcc version I got. Woohooo! Happy happy joy joy.
I don't mind the compiling part too much (well it basically sucks, but it is still tolerable), but finding all the patches... good god! :x
How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.
How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.
I have the impression that winavr is sometime more a fork than a port and that quite few things don't make it back into the gcc. maybe just due to the lack of motivation my Atmel to provide the work to make it happen. After all in winavr it works and other development platforms than Windows don't exist / are negligible (See the wonderful new Studio 5 based on Microsoft Visual Studio).
I think I'll have to agree with the fork vs. port part, but Atmel could at least have had the decency to use QT instead of the horrid MS stuff. It looks more and more like MS-word. Does it have ribbons as well?
And why do I need to register just for downloading a free-of-charge IDE? Is that strictly legal, having to register to get access to software that is - at least partially - licensed under the GPL?
Sheesh. Isn't it enough that I buy some of their chips already. Knowing who I am and what I do won't miraculously octuplicate their sales and blow away their competitors...
I installed AVR Studio 5 yesterday - it supports Tiny4313. When it was pointed out to Atmel that they'd shot themselves in the foot by delivering (again) a Windows only package the retort was that while the IDE may be tied to Windows the toolchain was "cross platform". Now I don't know how they can make that claim without providing Linux binaries x386 for the avr-* tools in the toolchain - but maybe they are lurking in there (I haven't looked)?
It was Dean, who said that the underlying stuff is cross-platform and only the IDE is Windows specific. This might be correct in theory and marketing speak (gcc is cross-platform), but in practice this is clearly false. After I pointed out to him that an 500MB exe file is not cross-platform did not venture any further comment.
I respect Dean and suspect he was carried away with his remark. I don't think he works in the Studio team, so he might just defend them without knowing all the details first hand.
I don't need a single click 500MB installer for linux, the script provided here is sufficient for most of us Linux guys. But it looks like we are deliberately ignored.
It basically does all the work. Only currently (well yesterday) it unfortunately does not produce a version of avr-gcc that supports the tiny4313.
The best I could do myself was to apply a patch to avr-devices.c to make the compiler aware of that chip. But later the linker barfed about a missing .o file - which existed.
If atmel is so stuck-up to ignore everything beside windows, they can't be helped and will pay the price once MS faces its inevitable end. I just love companies taking advantage of open source software and give back nowt.
I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.
Maybe it's time that someone shoves that message up the a*ses of the bean counters in management.
I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.
I doubt that this is easily possible, as Studio 5 is based on the Microsoft proprietary Visual Studio environment. However, the C/C++ compiler is already cross-platform compatible, only that Atmel, in its infinite wisdom has choose only to distribute the Windows version. Over time they will have to release all the patches they have applied to it as gcc is licensed under the GPL.
It would have been very easy for them to base their Studio environment on a cross-platform environment like Eclipse, like most of the industry is doing it right now. It might even have been less work.
D:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR Toolchain>dir
Volume in drive D is DATA
Volume Serial Number is 3636-53FD
Directory of D:\Program Files\Atmel\AVR Studio 5.0\extensions\Application\AVR T
oolchain
01/03/2011 20:47 .
01/03/2011 20:47 ..
01/03/2011 20:47 avr
01/03/2011 20:48 avr32
01/03/2011 20:47 bin
01/03/2011 20:48 contrib
01/03/2011 20:48 doc
01/03/2011 20:47 include
01/03/2011 20:47 info
01/03/2011 20:48 lib
01/03/2011 20:48 libexec
01/03/2011 20:49 man
01/03/2011 20:49 share
0 File(s) 0 bytes
Like "toolchain" before it they haven't bothered to include a source/*/*.patch directory.
In the past I know that people have used the *.patch that Eric included in WinAVR and have then applied them to a Linux built toolchain - as Toolchain/AS5 stands that is not possible and it does suggest Atmel is in violation of GPL as they are providing binaries for which the end user cannot easily rebuild them. At the very least they should just include a list of which patches have been applied and leave it to the builder to locate them from open FTP/HTTP sources.
Thanks for all the answers.
The key of the mystery was the path. I've supposed the /usr/local/avr/bin path will be added to my path by the script - and even worse, there was that forgotten, partly aborted version of avr toolchain.
Now as I set the path, everything is right. Thanks for the script, Bingo!
Istvan
- Log in or register to post comments
Top- Log in or register to post comments
TopBingo,
It took me a while to remember how to do PHP but I've updated the index.php on the website to give some very brief instructions including a note about setting the PATH
Cliff
- Log in or register to post comments
TopNaajzzz 8)
Thanx Cliff :-)
/Bingo
- Log in or register to post comments
TopHi,
I'm using avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb package and I'm trying to program an avr ATXMega256A3. Compiling with avr-gcc and flashing with avrdude works great. I use an MKII Jtag ICE to upload the application on the flash and I'm trying on chip debugging. It looks like on chip debugging is working right as when I hit CTRL+C it stops running and gdb tells me the instruction where the application stopped.
However I can't watch / display variables nor set/delete breakpoints.
Xmega256A3 data is store in SRAM (0x802000 <-> 0x805FFF). when I try to print a variable, and watch avarice debug, I see something like this:
As you can see from the debug information, gdb asks for location (0x800000 + 1) and does not account for the data offset NOR for the fact that data is stored on the ATXMega starting from the higher addresses (0x805FFF) up to the lower ones).
I wonder if it's gdb or avarice responsibility to account for these offsets...
I'd really appreciate your help guys...
Thankx in advance
I'm be waiting for any comment help hint or scolding me..
R
- Log in or register to post comments
Top@riccardomanfrin
Afaik there is no Xmega support in the "GNU" debugging tools , due to Atmel not releasing the neded info.
But i can see Jörg (avarice maintainer) inviting you to a dialog
https://www.avrfreaks.net/index.p...
/Bingo
- Log in or register to post comments
Top@04-jun-2010
Updated the buildscript to build insight 6.8-1
/Bingo
- Log in or register to post comments
Top@30-jun-2010
First release with avrlibc-1.7.0 here
https://www.avrfreaks.net/index.p...
/Bingo
- Log in or register to post comments
TopFYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.
For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.
Regards
Vidar (Z)
----------------------------------------------------------
"The fool wonders, the wise man asks"
- Log in or register to post comments
Top@Zainka
Did you have a look in the Pre-reqs.txt , file in the package.
- Log in or register to post comments
TopUploaded Jörgs mfile tool mfile-ubuntu.tar.gz , adapted for ubuntu (1 line change)
http://www.wrightflyer.co.uk/avr...
See Readme.ubuntu
/Bingo
- Log in or register to post comments
Tophow about GCC 4.3.5?
- Log in or register to post comments
TopWhat's in 4.3.5 that you "really" need ?
/Bingo
- Log in or register to post comments
TopReally? Mainly sport interest.
- Log in or register to post comments
TopIf you have used the above link
https://www.avrfreaks.net/index.p...
See
https://www.avrfreaks.net/index.p...
For fixing the delay bug in avr-libc-1.7.0
/Bingo
- Log in or register to post comments
TopThe scripts use a dangerous approach of assuming various directory creation and navigation commands work and then executing "rm -fr *" without ensuring that the current directory is what it should be. I had to spend a good chunk of last Sunday restoring from backup after one of the scripts wiped out a large part of my home directory.
Following the scripts and attempting to replicate the build process by hand yields a toolchain that works for tiny26 and mega32 projects, but can not find C runtime files for the xmega32A4:
This file does exist, it's in /Users/cjh/avr/avr/lib/avrxmega2/crtx32a4.o (prefix is $HOME/avr/). Moving it into the project directory yields different errors with libmath and libc:
Omitting -lm yields:
The files appear to be the right type:
And similar for the libraries, but long lists of entries of the same format and architecture "avr".
I'm using Mac OS X 10.6.5. The major differences from the scripts are that I'm using avr-libc-1.7.0, more recent versions of GMP and MPFR, and removing an instance of tree-inline.o from the GCC makefiles to fix a duplicate symbols problem. (bug in Snow Leopard's linker...won't ignore duplicate symbols from static libraries)
Any suggestions?
- Log in or register to post comments
TopI'm sorry if the script has caused you trouble.
You dont write what buildscript-filename , shell-file and line that caused you trouble.
So i'll assume it's this buildscript https://www.avrfreaks.net/index.p... , and the buildavr-cleanup.sh script.
And there is actually a warning when using that.
In the readme it states
And in the post that the above url refers to : It states
So if it was the cleanup script causing the trouble. The info (warning) was there , and you are the first that i know of , to have been "bitten".
The buildavr-cleanup.sh , was a quick "hack" because some users complained about the finished toolchain being 500MB+
As stated , the script are only tested on Ubuntu.
But a lot of people reports that with minor "adaptation" it also works on other *nixes.
/Bingo
- Log in or register to post comments
TopFor the problem . maybe try the toolchain from femtoos
http://www.femtoos.org/
Download
http://sourceforge.net/projects/...
Ruud's script is probably what you want (lots of checkking) , and is supposed to be functional on MAC.
/Bingo
- Log in or register to post comments
TopThat is the buildscript I used, but it was get-patches.sh that blew away part of my home directory. There's several times that it does mkdir's and cd's without checking for failure, blindly does "cd ..", and it simply experienced a couple failures and climbed up into my home directory before doing another "rm-fr *".
It would be much better to always specify full absolute paths, especially in the rm command. This alone would have prevented the issue, since it would have been trying to rm a nonexistent directory...it would not matter if it were in the wrong directory following a failure. I would also suggest simplifying it to put everything in a fully specified build directory rather than constantly creating and deleting this and that...it would be simpler, clearer, and less fragile.
As for the readme, I strongly suggest reorganizing it. There's no clear starting point for figuring out how to use the scripts, the quoted portion at first glance appearing to be an old portion of the revision history.
I will check out the femtoos scripts.
- Log in or register to post comments
TopFunny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?
- Log in or register to post comments
TopIt's good you've never had them run amok, because they would have done a lot more damage if you were blindly following those directions. Running the scripts with the root or sudo privileges needed for an install to /usr/local would not have improved matters...it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there. As it was, I noticed it was misbehaving when it started hitting files it didn't have the permissions needed to delete.
And yes, aside from limiting the potential damage from misbehaving scripts, building a standalone toolchain makes it trivially easy to switch between different versions of a toolchain, and keeps all the stuff related to that toolchain in one place. I didn't install to /usr/local because I didn't want it there.
It's clear that there's a major issue with the scripts' assumptions that directory creation and navigation will always succeed, coupled with running a dangerous command without any sanity checks. That you've never had trouble does not change the fact that failures can lead to it blindly deleting everything in higher level directories. Depending on the choice of download locations and how closely the directions are followed, it can delete nearly everything on the hard drive, OS included. Is your response to this really "it always worked for me" followed by questioning my choice of install locations?
- Log in or register to post comments
TopWouldn't matter to me - I use VM's - if it ever gets corrupted I return to a previous snapshot or recreate it.
- Log in or register to post comments
TopWell it's always nice with some feedback , even though you are the first i have heard about that has lost control.
And people has been using the scripts for four years now.
With the above mentioned readme et all.
I hope Ruud's script lives up to your expectations.
Edit: I can see it loose control if you are calling the scripts from another location. As it can't source the package-versions file.
Maybe i'll add a check for that.
/Bingo
- Log in or register to post comments
TopWell good for you! Can you at least admit that this might be something of an issue for other people?
It's simple. Potentially crawling up your directory tree and deleting everything in sight without warning is not desired behavior, okay?
:shock:
Look. Running the scripts as instructed is potentially equivalent to typing "sudo rm -rf *" in any containing directory, up to and including the root directory of the filesystem. This is a major issue that needs fixing, the scripts in their current state are brittle and fail catastrophically. That you haven't had reports of issues up to now is pure luck. You have now had such a report, and a clear description of what the problem is and why.
There is no reason to clear out unneeded files by attempting to cd to a location and then deleting everything in the current working directory. Simply working out what directory the items to be deleted should be in and passing that to rm will avoid the issue...if the directory doesn't exist, the script won't fail by crawling up the directory tree deleting everything in its path. This doesn't take a huge amount of effort to implement, and doesn't make things harder to maintain or follow...if anything, it makes it clearer what the scripts are doing and easier to ensure that they do only what you want.
- Log in or register to post comments
TopIf it's so easy for you to do , why don't you submit the modified script here.
Nothing stops you from helping out.
Then maybe i'll get my first patch , along with the first
Have a nice life , and i'll consider to make it a FLASH guide in my next version.
/Bingo
- Log in or register to post comments
TopHi,
Sorry for the cross-posting. I am trying to make a 1-file-only build script for the last version of the avr-gcc/avr-libc tools, as mentioned here:
https://www.avrfreaks.net/index.p...
The script uses the information on Bingo's scripts but is adapted from the scripts used to install the cross-compilers for arm.
In short:
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"
I was able to build the version 4.5.1 previously but not sure why I run into some trouble now that I try with 4.5.2. After installation, when I use avr-gcc I get this message:
(more information on the link above).
I know there are packages for ubuntu, but they are broken (again, see my unreplied post at the link above).
I am not able to attach the script file (I think there is a problem with the avrfreaks website, not sure), so here it is:
http://www.cl.cam.ac.uk/~osc22/f...
I hope some of you will find it useful (especially if I manage to fix this error).
Thanks.
- Log in or register to post comments
TopNice script ..
But why do you want the latest GCC ? , especially for a target like AVR.
Those patches in my buildscript is actually enabling/fixing a lot of things in the various packages.
I haven't got a good idea for your problem , but was wondering why you have/need these two options on the "configure" --program-prefix=avr- --with-gcc
/Bingo
- Log in or register to post comments
TopThe 2 parameters are a remainder from the original arm-gcc-cross-compiler building script. However both of them are correct and do not affect in a negative way the building of the tools (feel free to try).
The package for ubuntu, available here:
http://www.wrightflyer.co.uk/avr...
is broken as I have mentioned. It did not include the patch for delay.h.in in the avr-libc-1.7.0. One more reason why to have a building script functional that can be easily modified (I find more easy to modify my script than yours, no offence).
Why GCC-4.5.2? Well, I believe is better to go with the latest version, since they generally bring improvements. However, after a little Google (one of my friends suggested I need some practice on this...):
- from http://gcc.gnu.org/gcc-4.5/chang...
- new link-time-optimizer (sounds nice from description)
- automatic parallelisation pass
- optimising exception handling code (probably doesn't apply to our AVR targets, but still nice)
- just C related:
- -Wenum-compare option to warn about different enum types
- Added support for these new AVR devices:
ATmega8U2
ATmega16U2
ATmega32U2
- it is now possible to extend the compiler without having to modify its source code
- from http://gcc.gnu.org/ml/gcc-announ...
- improved loop optimization infrastructure
- GCC 4.5.0 also features improvements for a wide variety of specific
architectures, including support for recent CPUs using the ARM, AVR...
- many more ... (please read the links above).
Hope this will trigger some support.
Thanks.
- Log in or register to post comments
TopThe wisdom of the libc/avr-gcc maintainers is almost always the better place to start. It takes for fracking ever for anything to actually get released into gcc. And new processors are going to be unstable for a while. The patches that bingo uses which are from the toolchain maintainers mouths are based on the latest and most stable versions for this processor.
Period.
- Log in or register to post comments
TopOk, I've managed to fix the problem (thanks Bingo, gcc and avr-gcc community) - I was using a wrong parameter for make.
The last version of the building script is here:
http://www.cl.cam.ac.uk/~osc22/f...
Current versions (see the script to be sure):
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"
Bingo if you (and others) find it useful, feel free to add it on the first page.
Thanks.
- Log in or register to post comments
Top@goodhack
I suppose it was EW's hints on the avr-gcc list what brought you on track.
Congratulations in writing a very nice buildscript.
It still amazes me though :
That you chose to ignore the warnings in the last posts about using the unpatched upstream avr-gcc.
Instead of the proven 4.3.4 with the current maintainer patches applied.
These patches are created by Eric Weddington (WinAVR) , who adviced you on the "list". And Jörg Wunsch (avr-libc & FreeBSD port of avr-gcc).
And i sincerely hope your students won't be bitten , as these patches most likely haven't gone into the version of GCC that you are using.
/Bingo
- Log in or register to post comments
TopYes, it was EW's hints on the avr-gcc (as well as some other messages on the gcc-help list) that have helped me.
Well, it is not that I choose to ignore, I just want to provide a working script for the last version of GCC for those (like me) that want to use it.
Also, using your scripts, or the maintained 4.3.4 packages give extra work like applying missing patches.
I am sure the 4.3.4 version might be more stable, but why not trying to make it work with the current version?
Regarding the patches you refer to, I think that many patches have gone into the current (4.5.2) GCC version; at least from the Changelogs it seems that some things related to AVR have been aded.
Omar
- Log in or register to post comments
Top@Omar
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.
Btw: The reason i haven't updated the .deb packages with the new delay.h is that i follow the FreeBSD source like 99.9% , and Jörg hasn't released avr-libc-1.7.1 yet.
But your post actually made me upload the correct delay.h file , and write a warning in the "readme's" on http://www.wrightflyer.co.uk/avr...
Now you don't need to patch , just replace a file
/Bingo
- Log in or register to post comments
TopNice to hear about the correct file.
Thanks.
- Log in or register to post comments
TopHi,
nice scripts, thank you. :)
However, it aborted while building avarice-2.10 with a linker error on Arch Linux (AMD64):
On Arch Linux AMD64, avarice needs to be linked against libld:
I added
to the avarice-2.10 configure.ac file.
Then run autoreconf && autoconf , build a new tarball, exchange it and it works. :)
- Log in or register to post comments
TopHi bofh,
I am happy to hear you can use them as well.
Regarding the bfd problem, you should install libbfd. In ubuntu this is solved by installing binutils-dev, as mentioned in the header of the scripts.
- Log in or register to post comments
TopWould you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.
I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.
avrfreaks does not support Opera. Profile inactive.
- Log in or register to post comments
TopI don't have any examples , but i'm quite sure that it was Eric (EW) mentioning this on one of the mailinglists. As an answer to why patches wasn't moved upstream.
Ask Jörg or Eric.
/Bingo
- Log in or register to post comments
TopMega2560 has a bug in 4.5.2
https://www.avrfreaks.net/index.p...
http://gcc.gnu.org/bugzilla/show...
/Bingo
- Log in or register to post comments
TopThanks Bingo.
I have added a patch for the bug and I see the bug has now been fixed for GCC 4.6. Also I updated my script to use this patch.
Maybe we can make a complete list of unsolved bugs for 4.5.2 and hope they will all be fixed for release 4.6. And we could try to start converging from there.
- Log in or register to post comments
TopIs there a _single_ location available that at least links to all the files necessary to get up-to-date mcus working?
I must have spent have a day compiling (using the script and the manual on the avr-libc site) only to find out that e.g. my newly acquired ATtiny4313 is not supported by the compiled avr-gcc version I got. Woohooo! Happy happy joy joy.
I don't mind the compiling part too much (well it basically sucks, but it is still tolerable), but finding all the patches... good god! :x
How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.
- Log in or register to post comments
TopI have the impression that winavr is sometime more a fork than a port and that quite few things don't make it back into the gcc. maybe just due to the lack of motivation my Atmel to provide the work to make it happen. After all in winavr it works and other development platforms than Windows don't exist / are negligible (See the wonderful new Studio 5 based on Microsoft Visual Studio).
Markus
- Log in or register to post comments
TopI think I'll have to agree with the fork vs. port part, but Atmel could at least have had the decency to use QT instead of the horrid MS stuff. It looks more and more like MS-word. Does it have ribbons as well?
And why do I need to register just for downloading a free-of-charge IDE? Is that strictly legal, having to register to get access to software that is - at least partially - licensed under the GPL?
Sheesh. Isn't it enough that I buy some of their chips already. Knowing who I am and what I do won't miraculously octuplicate their sales and blow away their competitors...
/rant
Now back to business please :D
- Log in or register to post comments
TopI installed AVR Studio 5 yesterday - it supports Tiny4313. When it was pointed out to Atmel that they'd shot themselves in the foot by delivering (again) a Windows only package the retort was that while the IDE may be tied to Windows the toolchain was "cross platform". Now I don't know how they can make that claim without providing Linux binaries x386 for the avr-* tools in the toolchain - but maybe they are lurking in there (I haven't looked)?
- Log in or register to post comments
TopIt was Dean, who said that the underlying stuff is cross-platform and only the IDE is Windows specific. This might be correct in theory and marketing speak (gcc is cross-platform), but in practice this is clearly false. After I pointed out to him that an 500MB exe file is not cross-platform did not venture any further comment.
I respect Dean and suspect he was carried away with his remark. I don't think he works in the Studio team, so he might just defend them without knowing all the details first hand.
I don't need a single click 500MB installer for linux, the script provided here is sufficient for most of us Linux guys. But it looks like we are deliberately ignored.
Markus
- Log in or register to post comments
TopThe script is fine!
It basically does all the work. Only currently (well yesterday) it unfortunately does not produce a version of avr-gcc that supports the tiny4313.
The best I could do myself was to apply a patch to avr-devices.c to make the compiler aware of that chip. But later the linker barfed about a missing .o file - which existed.
If atmel is so stuck-up to ignore everything beside windows, they can't be helped and will pay the price once MS faces its inevitable end. I just love companies taking advantage of open source software and give back nowt.
I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.
Maybe it's time that someone shoves that message up the a*ses of the bean counters in management.
- Log in or register to post comments
TopI doubt that this is easily possible, as Studio 5 is based on the Microsoft proprietary Visual Studio environment. However, the C/C++ compiler is already cross-platform compatible, only that Atmel, in its infinite wisdom has choose only to distribute the Windows version. Over time they will have to release all the patches they have applied to it as gcc is licensed under the GPL.
It would have been very easy for them to base their Studio environment on a cross-platform environment like Eclipse, like most of the industry is doing it right now. It might even have been less work.
Markus
- Log in or register to post comments
TopThis is one major niggle I have with AVR Toolchain and now AVR Studio 5. If you go back to WinAVR then you have:
Whereas if you look at AS5 you have:
Like "toolchain" before it they haven't bothered to include a source/*/*.patch directory.
In the past I know that people have used the *.patch that Eric included in WinAVR and have then applied them to a Linux built toolchain - as Toolchain/AS5 stands that is not possible and it does suggest Atmel is in violation of GPL as they are providing binaries for which the end user cannot easily rebuild them. At the very least they should just include a list of which patches have been applied and leave it to the builder to locate them from open FTP/HTTP sources.
- Log in or register to post comments
TopSo where are the lawyers when you need them?
- Log in or register to post comments
TopIn case somebody missed this post, Atmel publishes the modified GPL-based stuff here:
http://distribute.atmel.no/tools...
- Log in or register to post comments
TopPages