As Ed wrote: > I also have another patch listed by the people on AVR freaks which is > from "Debian" for Avarice called: FTBFS: jtag2usb.cc:98: error: > invalid conversion from 'const char*' to 'char*' > the file is called "avarice_210.patch".
This has already been fixed in the CVS version, so start with what's in CVS right now. It's just I didn't have the time (and Internet bandwidth before) to roll a new release since. > It appears that the patch program does not like the fact that the > patch shows line 4485 is: " 72 * 4, // 72 interrupt vectors", > and the line in the original file is not the same. ( 71 * 4, // 71 > interrupt vectors). The original file experienced another bugfix meanwhile. The patch needs to be adjusted. The patch itself breaks the formatting, btw. It inserts spaces for indentation when the original file uses TABs. As Weddington, Eric wrote: > I can see that #2842239 is a one line change which, of course, is easy. Agreed. > #2995091 - Fix gcc 4.4.1 warnings Should be not too difficult either. I disagree with part of the patch though: - (void)write(ctrlPipe, cmd, 1); + (void)(write(ctrlPipe, cmd, 1) != 0); This fixes a warning that has been introduced by some operating system header, but I think the "fix" is just pointless. If the return value of a function is already explicitly cast to (void), this should clearly demonstrate the programmer's intention to (actively, rather than silently/blindly) ignoring the function's return value. If a certain operating system doesn't agree with that, the users should complain to the OS rather than me, or the package maintainer for that OS should add an OS-local patch. In my opinion, the suggested workaround is just obfuscating things, making it harder to read. As Ed wrote: [Ed, please use your mailer's reply button rather than starting from scratch, so the thread context remains intact.] > But it is also necessary to make sure all the latest patches to the > files for all the newer I.C's from Atmel are included. Keep in mind that the entire Xmega debugging is currently defunct as the appnote AVR067 doesn't document the breakpoint handling on Xmega devices. Thus, I don't think adding the respective patch would get you more than an "experimental" version of AVaRICE, which is still far away from being "production use ready". (My very personal consequence out of that dilemma is that I'm avoiding Xmega devices like the plague. They are of no value to me if I cannot debug them. The day I need a larger microcontroller, I'd seriously consider an ARM instead.) > SIMULAVR_VER="0.1.2.6" > > Although I still can't get Simulavr to build yet, I gave up after > about a week. Better try the simulavr version from the git repository. Version 0.1.2.6 is pretty outdated, and about the only reason it still exists at all is that avr-libc's testsuite uses it. Btw., we recently formed a mailinglist for some people who are actively trying to setup a toolchain build script in particular for Linux and MacOS X users. Do you want to join there? The idea is to start with the "Bingo600 Linux build script" that is floating around on avrfreaks.net. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ avarice-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/avarice-user
