Yes, it definitely sounds like your linker setup is not putting things in the right places.
Other possible problems: the libmaple headers rely on the environment to provide a bunch of #defines (like what board you're using, etc.), so you can't just configure Eclipse to tell GCC where to find the headers and call it a day. You can see the extra flags by doing a verbose libmaple build. For example, $ make V=1 library will build libmaple.a in verbose mode, so you can see all the extra stuff GCC needs to know. For example, on my machine, the output for a C++ file looks like this:
arm-none-eabi-g++ -Os -g3 -gdwarf-2 -mcpu=cortex-m3 -mthumb -march=armv7-m -nostdlib -ffunction-sections -fdata-sections -Wl,--gc-sections -DVECT_TAB_FLASH -DBOARD_maple -DMCU_STM32F103RB -DERROR_LED_PORT=GPIOA -DERROR_LED_PIN=5 -DSTM32_MEDIUM_DENSITY -I/home/mbolivar/leaf/libmaple/wirish [... other -I omitted ...] -I/home/mbolivar/leaf/libmaple/wirish -fno-rtti -fno-exceptions -Wall -DVECT_TAB_FLASH -DBOARD_maple -DMCU_STM32F103RB -DERROR_LED_PORT=GPIOA -DERROR_LED_PIN=5 -DSTM32_MEDIUM_DENSITY -MMD -MP -MF build//home/mbolivar/leaf/libmaple/wirish/boards.d -MT build//home/mbolivar/leaf/libmaple/wirish/boards.o -o build//home/mbolivar/leaf/libmaple/wirish/boards.o -c /home/mbolivar/leaf/libmaple/wirish/boards.cpp
Notice things like -DVECT_TAB_FLASH, -DSTM32_MEDIUM_DENSITY, etc. in addition to the include directories.
Anyway. Packaging libmaple for distribution, and generally writing projects outside of the libmaple tree, is definitely a deficiency that we need to correct. Until a better solution is provided, you have two choices:
1. Use libmaple's "library" makefile target to get build/libmaple.a compiled with all of our flags, build your application separately, and then use our linker script to put everything together.
2. Piggyback on our build system so you can keep a single copy of libmaple, but tell it to include your project sources in the build.
I'm not an Eclipse user, but I think that option (2) plus telling Eclipse to just use our Makefile is probably the quickest way to get what you want. I'll write up a quick tutorial on how and put it on the wiki, then update this thread once I'm done.
The important thing is that you need to use our linker script(s) and provide the appropriate linker flags so that it works. Again, I'm not an Eclipse user, but it sounds like the makefiles it generated aren't what you want. If the link goes wrong, then e.g. the vector table will be incorrect, and the reset vector won't point to _start (which is the assembly stub that sets up the call to start_c()). The linker script does other important things too, like provide symbols so start_c() knows how to initialize .data and .bss. If you link against libmaple in a way that violates the assumptions made in that script, Bad Things happen.
For an example call to the linker, you can again build some example in verbose mode. For example (on Linux):
$ ln -s examples/blinky.cpp main.cpp
$ make V=1 | grep Xlinker
The pipe to grep hides all the output except for the call to the linker. On my machine, that produces this output:
arm-none-eabi-g++ -T/home/mbolivar/leaf/libmaple/support/ld/maple/flash.ld -L/home/mbolivar/leaf/libmaple/support/ld -mcpu=cortex-m3 -mthumb -Xlinker -L /home/mbolivar/leaf/libmaple/support/ld/stm32/f1/performance --gc-sections --print-gc-sections --march=armv7-m -Wall -o build/maple.elf build//home/mbolivar/leaf/libmaple/libmaple/adc.o [ ... many object files omitted ... ] build/main.o -Wl,-Map,build/maple.map
The -T flag specifies the linker script. The -L flags specify search directories for ancillary linker script files.
Ok, off to write that tutorial; hopefully I'll update this thread soon.
