I got a bit farther along testing on the actual hardware again.
I am using code from Vasillis's code from around march of 2016 which I munged into my fork of the project.
I was able to hand modify the eclipse project to include the correct compiler flags. There are still quite a number of pedantic warnings which indicate that the code is not too stable. Things like missing breaks at the end of case statements. Values not initialized in constructors.
The main issue seems to be in the exported "extern USBD_HandleTypeDef hUsbDeviceFS;" which the compiler claims is never used. Internally there is a variable hUsbDevice_0 of the same typedef which the compiler barfs on and is the main reason usbd_cdc_if.c fails. It looks like some sort of glue is needed to link these two references. This error if it is seems to be an issue with the Hal library as this file is regenerated when ever the cube project code is built.
I sill have one issue with the CDT syntax scanner and utoa. The project includes stdlib.h even though the makfile states -nostdlib. Eclipse will not allow this to be right click deleted. I have not found where in the xml it is defined.
Running make from the command line works just fine. That is all the eclipse build command does anyway. Such adds an extra step.
Took some effort to get the gdb to work. The normal launch fails. launching through Debug configurations works just fine. The code however crashes in an exception handler, where Serial.begin(9600) is called from variant.cpp inside the USE_USBSerial ifdef. The values in these structures seems to be allocated before the HAL_init() is called in main.
I switched the ifdef off. The code then crashes in I2C_init() which is a different issue. I think I still have the old wiring lib in the source tree. I also turned everything on in the STM32CubeMX to see what code was generated.
Not sure about the variations of the Cube firmware library revisions. I noticed that the openSTM32 (Ac6) downloaded the HAL directly into eclipse. My rule (from my days at apple and lib revision hell.) is to use the latest version when at all possible.
I pushed these latest changes to my github fork. The most interesting file is the makefile https://github.com/sheepdoll/HALMX_Arduino_STM32/raw/master/HALMX/variants/MXNucleoF103/Makefile
If the Arduino arm tools path is set in the command line (.profile or what ever .bshrc is called) then make can build the project without any IDE. I used the trick of placing the stub for the .ino into a separate path (I think hard coded in the makefile) to a c++ stub (currently the blinky sketch) I call this folder Arduino_extra and it is where I put things that clutter up the main IDE.
The full path to the git fork is https://github.com/sheepdoll/HALMX_Arduino_STM32.git
Only the NucleoF103 has significant changes. There is also a makefile in the NucleoF401 which was my first attempt at a makefile project.