As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

So programming should be no problem. What have you tried, and how far did you get?

When it comes to debugging the game gets more complicated.

First piece of software "above" the Dragon is AVaRICE. Then on top of that goes GDB. With that you can do command-line-style debugging. E.g. to step you actually type "step" or some such. Everything (free-running, inspecting variables, setting breakpoints...) is done through the command-line interface (no windows, buttons etc).

If you want a better UI you need additional software on top of GDB. This could be anything from DDD (a "free-standing" client doing nothing but debugging) to complex IDEs (Eclipse, NetBeans, Insight, CodeBlocks...).

To get the whole shebang running, and all parts talking to another, some configuration and initialization scripts are needed.

It will not be the smooth plug-and-play ride it is using Atmel Studio on Windoze. Unless you are prepared to take some frustration, and is a reasonably experienced user when it comes to Linux, command lines etc I would advice against going for it if you have a Windows system up and running.

Yes, you can find tutorials, how-to's and the like on the Web. You will fins tidbits of the solution on your machine in them, but it will not all be in one such howto. Problem is that they all differ because the systems they where done on differ. There will be no cook-book recipe to follow to "just make it work". You will need to tinker, do detective work etc. (I've been on and off this for a few months, must have spent 40 to 80 hours, and am still not all the way with this..).

If you do go down this route then please report back with your experiences!

Advice: Keep meticulous notes of everything you do. You will need to back out and re-do things, and notes are essential!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

It turns out on linux, avr dragon requires libbfd.a. Whats strange is that I've been able to program, compile, more or less do what is required without that lib, which leads me to believe that its needed for whatever avr dragon uses to communicate. I've tested this with other linux machines, so I'm fairly confident in my reasoning.

But libbfd.a is a static library, so why would the Dragon "require" that?

A quick search seems to indicate that libbfd is a part of binutils, so that would have nothing to do with Dragon communication, I suppose.

What software are you using to program the flash of the AVR using the Dragon?

In your first post you mentioned "debugging". Have you had progress on this, using the Dragon? If so I would be interested in any experiences or results since I am (slowly) trying to put together some kind of HowTo for on-chip debugging of AVRs, using e.g. the Dragon, hosted by Linux.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.

No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

The only reason you'd need libbfd.a is if you are trying to BUILD a copy of avrdude. I think (like most programs that read HEX, ELF, etc) it uses BFD. But if you have a prebuilt copy of avrdude then the executable already will have the bits from libbfd.a it needs built in. If a running copy of avrdude need functions that were not built it it would be looking to load libbfd.so which is a dynamic library in Linux. But not the .a file, which as Johan says, is a static library.