I'll take a stab. I haven't written code for Arduino, but I've done a lot of C and C++ programming. It would help if I actually saw your errors, but nonetheless.
The main thing you need to always remember when using C++ with C code is that your C++ code needs functions declared with "extern "C"" if you want C code to be able to link against the C++ code. The "extern "C"" is what tells the C++ compiler that I'm creating linkable code for C files or I'm using code from C files. So all your functions in the library API header should correlate with a function in the source file defined liked "extern "C" void dosomething()". If you're trying to use classes in C++, remember that C code can't call it, you'll need to create functions (extern "C") to access the object. Now, if your C code is compiled with a C++ compiler, then don't worry about "extern "C"".
If you want to call C code inside your C++ code, then you need to wrap the C header with a construct like this:
#ifdef ___cplusplus
extern "C" {
#endif
///all my C function declarations... yada yada
#ifdef __cplusplus
} //end extern "C"
#endif
If you working in C++, don't use a lot a #defines unless you're creating compile-time flags like "DEBUG" or "VERSION2" to create special sets of code. Otherwise use "const int/char/float" for number defines for safe type checking. The compilers are usually smart enough to optimize these out, so they wind up in ROM/code space (depends though). Also, don't create MACROS, use inline functions. Also, don't always follow convention when programming if it's stupid such as using a lot of macros and number defines in C++. The same thing applies to C99 version of C, it has added things like inline functions and consts from C++. The industry realizes how much buggy code and hard to maintain code comes from overuse of the preprocessor language.
Eclipse usually stores the obj files in a directory under your project. If you're doing a "Debug" build, then it's located under the "Debug" folder under your project folder. If you're doing a "Release" build, then look under "Release", etc. Normally a clean build just works for me in Eclipse, so I don't know what's going wrong with your setup. I guess make sure you're not creating precompiled headers.
Best Answer
Your vector table will always be project-specific. The correct approach is to define the ISR inside the .c file of the relevant driver handling the hardware that the ISR belongs to.
If you need to expose the ISR name to the file containing the vector table, you should add a function declaration of the ISR in the .h file of the driver.
For example, if you are writing code that uses a UART peripheral of a specific MCU - lets call it "AVR123", then you should create a driver named something like "avr123_uart.h" + "avr123_uart.c". The ISR will be located in avr123_uart.c and all code communicating with the ISR will be there too.
If you need portable or platform-independent code, you can create a hardware abstraction layer (HAL) on top of the driver. Meaning you'll have a file "uart.h" which declares some functions uart_init, uart_read, uart_write and so on. These functions are then implemented in avr123_uart.c. We may say that "avr123_uart" inherits "uart.h" and that "uart.h" is an abstract base class.
The application call only includes uart.h but links the MCU-specific driver. That way you don't have to change a thing in the application code if changing hardware. Simply link the relevant driver.
Under no circumstances should you "splatter" ISR implementation all over the code, or place them in files that have nothing to do with the given hardware. No other code than the driver where the ISR resides should communicate with it.
See Avoiding global variables when using interrupts in embedded systems.