I'm still trying to figure out why the link step fails with VS2017CE/VM, but works fine in the Arduino IDE.

I have a very simple Example program for the MPU6050.  The library files are all in the sketchbook folder.  

The example compiles without errors or drama in the Arduino IDE  V1.8.7, but in VS2017/VM it blows a whole bunch of errors in the form of 

ccC9SzMc.ltrans0.ltrans.o*: In function main
   (.text.startup+0x1e4): undefined reference to MPU6050::initialize()

for every call to a MPU6050 class function.

I have attached a zip file containing the .INO file, all the required library files and the verbose compiler outputs from both the VS2017/VM setup and the Arduino configuration.   This should compile cleanly on any Windows PC, at least in the Arduino IDE.

The frustrating thing is, this USED to work fine in VS2017/VM and now I have descended into some kind of header file hell; I must have done something really bad in a previous lifetime .

I know Tim and others here have been very patient as I have tried to work through all this, but I'm pretty much at wit's end here.

I'm beginning to believe the VS2017/VM configuration is corrupted in some way, and I'm wondering it  might be useful to try to uninstall the entire VS2017/VM environment and build it back up again.  I'm perfectly willing to do that (after all, it can't be any worse than what I have now!), but I'm not quite sure what the best way to do that would be.  How would you recommend I go about removing all traces of VM from VS2017, removing all traces of VS2017 from my PC, and then putting it all back together again?

TIA,

Frank

Also, just discovered I didn't have compiler warnings turned on in the Arduino IDE.  When I re-ran the compile with 'Default' warning level, I got the same warnings (but not the same linker errors) as I did in the VS2017/VM setup, namely:

Linking everything together...
"C:\\Program Files (x86)\\Arduino\\hardware\\tools\\avr/bin/avr-gcc" -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections,--relax -mmcu=atmega2560 -o le.ino.elf" p.o" pp.o" MP6_Example.ino.cpp.o" Wire.cpp.o" utility\\twi.c.o" 54c.a" "-LC:\\Users\\Frank\\AppData\\Local\\Temp\\arduino_build_582967" -lm
C:\Users\Frank\AppData\Local\Temp\arduino_build_582967\sketch\MPU6050.h:436:7: warning: type 'struct MPU6050' violates one definition rule [-Wodr]

 class MPU6050 {

       ^

C:\Users\Frank\AppData\Local\Temp\arduino_build_582967\sketch\MPU6050.h:436:7: note: a different type is defined in another translation unit

 class MPU6050 {

       ^

 note: the first difference of corresponding definitions is field 'dmpPacketBuffer'

         uint8_t *dmpPacketBuffer;

                  ^

C:\Users\Frank\AppData\Local\Temp\arduino_build_582967\sketch\MPU6050.h:436:7: note: a type with different number of fields is defined in another translation unit

 class MPU6050 {

       ^

"C:\\Program Files (x86)\\Arduino\\hardware\\tools\\avr/bin/avr-objcopy" -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 le.ino.elf" le.ino.eep"
"C:\\Program Files (x86)\\Arduino\\hardware\\tools\\avr/bin/avr-objcopy" -O ihex -R .eeprom le.ino.elf" le.ino.hex"
Using library Wire at version 1.0 in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\Wire
"C:\\Program Files (x86)\\Arduino\\hardware\\tools\\avr/bin/avr-size" -A le.ino.elf"
Sketch uses 15550 bytes (6%) of program storage space. Maximum is 253952 bytes.
 

If you use the verbose option in the arduino ide you will see which libraries and being used and from what location.

If you do same in visual micro then you will see same and maybe then see a difference.

If you can't see a difference then create a very basic project that simply includes the libraries you are working with along with the basic example for the mpu6050 sensor. If that fails you can zip and email the project along with a note of which libs you have installed and from where to info@visualmicro.com

Questions

1) Why have you copied library sources into your project code folder?

2) Why have you switched off "vMicro>Compiler>Deep search for libraries"?

Thanks

If you are not using the libraries in documents\libraries then delete them or just use them as normal without copying local

Tim,

OK, I think I've finally nailed the entire thing down (sort of)

So, the original problem (back when I was still trying to drain the swamp) was two linker warnings - one about integer overflow in a calculation, and the other was the dreaded "One Definition Rule" (ODR) warning, which I had never  heard about until now - go figure.

Then, in the process of trying to fix the above problems, things started to blow up on me, resulting in multiple link errors on code that used to compile/link fine - yikes!

Long story short, most of my problems were self-inflicted (you knew that already, I'll bet).  One of the things I did to try and simplify the problem was to remove the i2cDev-related library files from Arduino\Libraries to prevent the compiler/linker from linking in extraneous header files (At the time I thought this might be the cause of the ODR violation).  What actually happened is now Visual Micro couldn't find these files AT ALL, even though they were all in the local project folder and I had 'local files override library files' checked.  

After tearing most of my remaining hair out (and bugging you unmercifully) I created two identical projects, one of which compiled/linked fine (with the ODR warning still) and one of which wouldn't link at all in VS/VM.  However, BOTH projects compiled/linked fine in the Arduino IDE, so now I knew it had to be something in the VS/VM project/solution configuration that was causing the problem.  Eventually I stumbled on the 'solution' in the project that worked, I had earlier added the relevant library .H/.CPP files to the 'working' project using Solution Explorer so they showed up under the 'Header Files' and 'Source Files' folders.  After adding the library files to the non-working project, it started compiling/linking successfully as well.

IMHO, this is a bug in Visual Micro.  If the 'local files override library files' option is enabled, whether or not the files are added to the project in Solution Explorer shouldn't matter.  If files MUST be added to the project via Solution Explorer to be 'seen', then why have the 'local files override...' option at all?  Shouldn't the compiler always process files that are added to projects via the Solution Explorer?

So, now I was back to square 1, with projects that compiled/linked, but still with ODR warnings.  After LOTS of web research, I finally figured it out - the original author of the MPU6050 class had placed an #ifdef/#endif statement in the class definition in a way that (from the compiler's point of view) could result in two different definitions of the same class.  Temporarily commenting out the #ifdef/#endif in the class definition suppressed the ODR warning - SUCCESS!!!


Regards,

Frank

Tim@Visual Micro wrote on Feb 5^th, 2019 at 5:42pm:



Tim,

As I mentioned 3 days ago in this thread, I didn't notice initially that warnings were turned off in the Arduino IDE:

Reply #2 - Feb 1st, 2019 at 3:14am:  Also, just discovered I didn't have compiler warnings turned on in the Arduino IDE.  When I re-ran the compile with 'Default' warning level, I got the same warnings (but not the same linker errors) as I did in the VS2017/VM setup, namely: ....

Frank