For the most part, it doesn't really matter as long as you have a standard and are consistent among projects in the same programming language. You should generally create a document that explains how to count source lines of code and how to configure any tools that you use to use this method.
In C++ for example, should I count the lines of the header files with my class definition?
I would. You did write them after all, and they are used in the build process of your software.
Should I count the header of a (non standard) library I am linking against?
Yes, you can, if you are tracking code reuse. If you have the capability to count lines of code from other projects (either your own or open-source projects), you can consider that code reuse and use it when computing various reuse-related metrics.
In Qt (or any other GUI framework), should I count the lines of the form's design?
If you wrote them, I say yes. If they were automatically generated, then perhaps. If you do it once, you should do it consistently. Perhaps you want to consider counting generated code separately than hand-written code.
Should I count the Makefile too?
I would say no, as it's a supporting tool and not part of your built application. Again, going back to the GUI framework question, if it's autogenerated, perhaps you want to count it separately. Or perhaps you want to count "build scripts" separately and include things like Makefiles, Ant scripts, and so forth.
A manager recently announced that were were spending far too much time fixing bugs.
Above sounds very ignorant. Suggested reading for cases like that: Facts and Fallacies of Software Engineering by Robert L. Glass, particularly "Fact 43. Maintenance is a solution, not a problem."
Wikipedia article mentions 80% efforts spent on software maintenance.
my manager makes Dilbert's PHB look like a genius :)
Hm given above I'd also take some efforts in analyzing whether all the requests you do are bugs indeed.
In my experience it was way too often that requests for enhancements or new features were submitted as bugs. Good managers involve their programmers in finding out about that - bad managers, well, just keep complaining about too much time fixing bugs.
Best Answer
The only concrete measure for an employed developer is the number of hours spend coding and fixing bugs, and the money you get paid for it. If you are staying late at night 6 days a week for 50K US$ a year, then you have a problem. No matter how many lines of code your boss want you to be responsible for, you won't handle more than you can do, taking account of a certain code quality of course. Developing poor quality code with no unit tests is a good way to handle much more code, but the company will have to pay the price of a large technical debt.
In small companies developers tend to be responsible for much more code than in large corp. The factor 3 to 10 you are referring to seems realistic to me.