avr-gcc 1.4.8 in windows sometimes ommits drive and start of path.

[jantje]

Users of my arduino eclipse plugin report strange behaviour since Arduino IDE 1.5.7.
After investigation it turns out that avr-gcc sometimes returns wrong information when running the command to get the "included folders and defines" in certain folder setups.
To be concrete when Arduino IDE 1.5.5 is installed in r:/test/ and the following command is run from r:/test/
hardware\tools\avr\bin\avr-g++" -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=158 -DARDUINO_AVR_PRO -DARDUINO_ARCH_AVR -D__IN_ECLIPSE__=1 -E -P -v -dD R:/Test/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
it will return (for full listing see http://pastebin.com/ZeLiC7TV)
... ignoring nonexistent directory "r:/test/arduinoide/hardware/tools/avr/lib/gcc/../../avr/include/c++/4.3.2" ignoring nonexistent directory "r:/test/arduinoide/hardware/tools/avr/lib/gcc/../../avr/include/c++/4.3.2/avr/avr5" ignoring nonexistent directory "r:/test/arduinoide/hardware/tools/avr/lib/gcc/../../avr/include/c++/4.3.2/backward" ignoring nonexistent directory "r:/test/arduinoide/hardware/tools/avr/lib/gcc/../../avr/sys-include"

when Arduino 1.5.7 is installed in r:/test/ and the same command is run from r:/test/ you get
`cygwin warning:
MS-DOS style path detected: R:/Test/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C

...
ignoring nonexistent directory "/ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4.8.1"
ignoring nonexistent directory "/ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4.8.1/avr/avr5"
...`
As you can see cygwin is reporting a path issue and the R:/test folder is missing from the include paths
With Arduino IDE 1.5.8 the same result is happening.

I think this is a glitch because when using Z:\windows as folder the problem does not occur.
rlogiacco and I have documented our steps in a issue (ignore the title and the part about the missing makefile) #arduino-eclipse-plugin/183
Sloeber/arduino-eclipse-plugin#183 (comment)

[rlogiacco]

Let me add I've checked this same problem occurs on drive D: as well, it seems it is somehow omitting the drive letter and one folder level.
In the reported pastebin it is omitting R:\Test as the correct installation folder of Arduino IDE is R:\Test\ArduinoIDE\.

[matthijskooijman]

Weird. I think that Windows does have the concept of an active drive, so you can refer to C:\Foo as \Foo when C: is active, but that doesn't explain why Test is ommitted.

What seems weird is that in the end it does seem to end up with an include path?

#include <...> search starts here:
 /ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include
 /ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include-fixed
 /ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include

This error message is also weird:

MS-DOS style path detected: R:/Test/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
  Preferred POSIX equivalent is: /Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C

It also omits R:/Test from the preferred path.

You say R:\test is the current directory (though in that case hardware\tools\avr\bin\avr-g++ wouldn't be correct?). Perhaps it is just interpreting paths relative to the current directory?

The cygwin docs don't really help here either, they suggest you'll need an fstab file to mount Windows-style pathnames (using drive letters) into a UNIX-style /-based hierarchy. They do say:

A default root directory is evaluated at startup so a fstab entry for the root directory is not necessary.

So perhaps cygwin is picking R:\Test as the root directory?

I'm inclined to say this debug output looks ok and there is no problem, but you didn't start all this for nothing :-) Reading the original report, I couldn't easily find the original problem, though, care to show some commands here that show the actual failure?

[rlogiacco]

Current directory is R:/Test/ArduinoIDE and the active drive concept is
correct as everything works fine if the location is moved to R:/ArduinoIDE

Il venerdì 7 novembre 2014, Matthijs Kooijman [email protected] ha
scritto:

Weird. I think that Windows does have the concept of an active drive, so
you can refer to C:\Foo as \Foo when C: is active, but that doesn't
explain why Test is ommitted.

What seems weird is that in the end it does seem to end up with an
include path?

#include <...> search starts here:
/ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include
/ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include-fixed
/ArduinoIDE/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include

This error message is also weird:

MS-DOS style path detected: R:/Test/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Preferred POSIX equivalent is: /Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C

It also omits R:/Test from the preferred path.

You say R:\test is the current directory (though in that case
hardware\tools\avr\bin\avr-g++ wouldn't be correct?). Perhaps it is just
interpreting paths relative to the current directory?

The cygwin docs
https://cygwin.com/cygwin-ug-net/using.html#using-pathnames don't
really help here either, they suggest you'll need an fstab file to mount
Windows-style pathnames (using drive letters) into a UNIX-style /-based
hierarchy. They do say:

A default root directory is evaluated at startup so a fstab entry for the
root directory is not necessary.

So perhaps cygwin is picking R:\Test as the root directory?

I'm inclined to say this debug output looks ok and there is no problem,
but you didn't start all this for nothing :-) Reading the original report,
I couldn't easily find the original problem, though, care to show some
commands here that show the actual failure?

—
Reply to this email directly or view it on GitHub
#2422 (comment).

[jantje]

@matthijskooijman
The problem in general is "the arduino eclipse plugin" "may not work" on windows with arduino IDE 1.5.7 or higher. The may or may not work is dependent on your arduino IDE location.

The reason for that is that the "avr-g++ -E -P -v -dD spec.c" command is designed for (and used by CDT) to find all "compiler specific include and library paths and defines". As the R:/Test is removed from the include and library paths most indexer based eclipse services fail due to bad compiler include paths.

As the "path gathering" is actually the CDT way (and documented gcc way) I'm sure we can say "the arduino IDE 1.5.7 and higher do not work as a toolchain in eclipse"

Here are the compilation options described that I think are being used. All info below comes from https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#Preprocessor-Options
If you use the -E option, nothing is done except preprocessing.
-v
Verbose mode. Print out GNU CPP's version number at the beginning of execution, and report the final form of the include path.
-dCHARS
CHARS is a sequence of one or more of the following characters, and must not be preceded by a space. Other characters are interpreted by the compiler proper, or reserved for future versions of GCC, and so are silently ignored. If you specify characters whose behavior conflicts, the result is undefined.

M
Instead of the normal output, generate a list of ‘#define’ directives for all the macros defined during the execution of the preprocessor, including predefined macros. This gives you a way of finding out what is predefined in your version of the preprocessor. Assuming you have no file foo.h, the command
touch foo.h; cpp -dM foo.h will show all the predefined macros.
If you use -dM without the -E option, -dM is interpreted as a synonym for -fdump-rtl-mach. See Debugging Options.
D
Like M except in two respects: it does not include the predefined macros, and it outputs both the #define directives and the result of preprocessing. Both kinds of output go to the standard output file.

-P
Inhibit generation of linemarkers in the output from the preprocessor. This might be useful when running the preprocessor on something that is not C code, and will be sent to a program which might be confused by the linemarkers.

[matthijskooijman]

Ok, thanks for providing the context.

I think that gcc is not doing anything wrong - it's outputting the proper pathnames. However, it is outputting them as UNIX-style paths, using R:\Test as the root / of the filesystem. To properly interpret these paths, you'll need to know what / points to. So I can see two solutions:

• Run the "mount" command (if it's included, not sure) to find out what / points at
• Make sure that / doesn't point at any path involved in the output. AFAIU this can be done by changing the current directory to e.g. C:\Windows or something like that?

I'm wondering where this change in behaviour comes from, and if any of the other CDT tools are suffering from this too. Is it a cygwin version change, or a gcc version change that caused the change?

[rlogiacco]

I've changed the current directory to one folder upward, from R:\Test\ArduinoIDE to R:\Test and modify the command appropriately, but it doesn't help: actually the 1.5.7 and 1.5.8 fails because of a missing cygwin1.dll. I'll try immediately running it from C:\Users, but I expect the same error to pop up.

[rlogiacco]

I confirm, the same error pops up with a message (translating from Italian here): Cannot run the program due to missing cygwin1.dll. To solve the issue try re-installing the software.

It seems the problem is to properly identify the compiler's path as that is reported correctly by 1.5.5 but incorrectly by 1.5.7 and 1.5.8.

I can run other tests if you wish, one thing I've tried is to use a different folder name R:\Windows instead of R:\Test and a different drive and folder D:\Tools with no joy so far.

I had GNU Coreutils installed and tried to remove that, still no joy.

[rlogiacco]

mount.exe was not included, but I did copy the utils folder from 1.5.5 and run it with the following command r:\windows\arduinoide-1.5.7\hardware\tools\avr\utils\bin\mount.exe (note I've renamed R:\Test into R:\Windows as stated in my previous reply) and here is the output:

r:\windows\arduinoide-1.5.7\hardware\tools\avr\utils on /usr type user (binmode,noumount)
r:\windows\arduinoide-1.5.7\hardware\tools\avr\utils on / type user (binmode,noumount)
C:\Users\RLOGIA~1\AppData\Local\Temp on /tmp type user (binmode,noumount)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)
f: on /f type user (binmode,noumount)
r: on /r type user (binmode,noumount)

Launching folder was C:\Users\rlogiacco.
And in case you wonder, yes, I do have all those 5 drives on my system.

[rlogiacco]

And here is another test.
I've moved to an additional nesting directory R:\Test\Setup, moved in there and executed the avr-g++ command and reported compiler path is still /ArduinoIDE-1.5.7: it seems it is taking the current execution folder and assuming it is a root, no matter what's above that point.
That would explain the missing DLL error as well when run from a different path.

[rlogiacco]

Weird enough I just tried another configuration, moving the Eclipse folder one level out, so that I now have R:\Test\Setup\ArduinoIDE-1.5.8 and R:\Test\Eclipse (Eclipse is no longer a sibiling of ArduinoIDE) and the output has changed!
The cygwin warning now reports:

  MS-DOS style path detected: R:\Test\Eclipse\workspace\.metadata\.plugins\org.eclipse.cdt.managedbuilder.core\spec.c
  Preferred POSIX equivalent is: /cygdrive/r/Test/Eclipse/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.c
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
    http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

Note /cygdrive/r has been added, but the include search still reports wrong, non absolute, paths:

#include "..." search starts here:
#include <...> search starts here:
 /ArduinoIDE-1.5.8/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include
 /ArduinoIDE-1.5.8/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include-fixed
 /ArduinoIDE-1.5.8/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include

[jantje]

@matthijskooijman

I think that gcc is not doing anything wrong - it's outputting the proper pathnames.

I'm sorry to say I disagree. IMHO the behaviour is a bug. This for following reasons

1. the behaviour is non consistent.
   According to the test rlogiacco did (see original issue) D:\Parent\eclipseArduino works but D:\Bundle\ArduinoIDE. fails. On my system Z:\windows\arduino-1.5.8 works.
2. The path is wrong
   As the mount info of rlogiacco shows r: is mounted on /r so the cygwin path should be /r/test/hardware.... which makes perfect sense but /hardware does not make sense.
3. yes the path is wrong
   if the returned pats is a relative path it should be hardware/... and not /hardware/... .
   Having the path start with / makes it is not a relative path
4. and the path is even wronger
   Assume that the path returned is /r/test/hardware.... then still it would be not acceptable. I think it is okish for avr-gcc to rely on cygwin but it is unacceptable for it to return cygwin paths on a OS that is not compatible with these paths.

I think it is a pretty complex problem as it involves gcc, cygwin and a glitch. IMHO it is a bug all-right.

[rlogiacco]

Apologies for the correction Jantje, but D:\Parent\eclipseArduino was
erroneously reported working by me just because it happened I had
D:\ArduinoIDE, which mixing up the current drive and relative-absolute path
messing produces a match.

On my environment (Win 7 Ultimate 64bits) it fails pretty consistently.

Can you check if you have an Arduino IDE installation on your Z drive root?

Il venerdì 7 novembre 2014, jantje [email protected] ha scritto:

@matthijskooijman https://github.com/matthijskooijman

I think that gcc is not doing anything wrong - it's outputting the proper
pathnames.

I'm sorry to say I disagree. IMHO the behaviour is a bug. This for
following reasons

1. the behaviour is non consistent.
   According to the test rlogiacco did (see original issue)
   D:\Parent\eclipseArduino works but D:\Bundle\ArduinoIDE. fails. On my
   system Z:\windows\arduino-1.5.8 works.
2. The path is wrong
   As the mount info of rlogiacco shows r: is mounted on /r so the cygwin
   path should be /r/test/hardware.... which makes perfect sense but /hardware
   does not make sense.
3. yes the path is wrong
   if the returned pats is a relative path it should be hardware/... and not
   /hardware/... .
   Having the path start with / makes it is not a relative path
4. and the path is even wronger
   Assume that the path returned is /r/test/hardware.... then still it would
   be not acceptable. I think it is okish for avr-gcc to rely on cygwin but it
   is unacceptable for it to return cygwin paths on a OS that is not
   compatible with these paths.

I think it is a pretty complex problem as it involves gcc, cygwin and a
glitch. IMHO it is a bug all-right.

—
Reply to this email directly or view it on GitHub
#2422 (comment).

[matthijskooijman]

I didn't say that this wasn't a bug per-se, just that it's not gcc's fault. It seems gcc was compiled against cygwin, which has some special path handling for Windows, which is a but unconventional and surprising, but there's probably some good reason for it. It's annoying that things are (or at least look) so unpredictible, though.

As the mount info of rlogiacco shows r: is mounted on /r so the cygwin path should be /r/test/hardware.... which makes perfect sense but /hardware does not make sense.

This seems true - the docs said that in case of multiple mounts the longest path is picked, which would be /r/.... Perhaps the output that mount gives does not correspond to the fstab that is used by gcc? If mount.exe was copied from another version, it's output might not be representative?

if the returned pats is a relative path it should be hardware/... and not /hardware/... .
Having the path start with / makes it is not a relative path

It's not a relative path, it's an absolute path that starts against /. Since Windows doesn't have a concept of /, / is mapped to R:/Test (or wherever, depending on the example), which makes it look like a relative path, but it really is an absolute path (in the Unix sense).

Assume that the path returned is /r/test/hardware.... then still it would be not acceptable. I think it is okish for avr-gcc to rely on cygwin but it is unacceptable for it to return cygwin paths on a OS that is not compatible with these paths.

Uh, CYGWIN is specifically a port of UNIX tools to Windows. When using CYGWIN, I think you are essentially using UNIX, not Windows :-p Having said that, using native win32 paths might be easier to integrate of course. There's probably technical reasons to not always use them (which I don't know).

I'm just responding to your remarks here directly. Unfortunately I don't understand what happens exactly either, so I can't offer any suggestions for a solution :-(

and run it with the following command r:\windows\arduinoide-1.5.7\hardware\tools\avr\utils\bin\mount.exe

What happens when you make r:\windows the current directory and run arduinoide-1.5.7\hardware\tools\avr\utils\bin\mount.exe (so using a relative path)?

[rlogiacco]

Here you go

R:\Windows>ArduinoIDE-1.5.7\hardware\tools\avr\utils\bin\mount.exe
R:\Windows\ArduinoIDE-1.5.7\hardware\tools\avr\utils on /usr type user (binmode,noumount)
R:\Windows\ArduinoIDE-1.5.7\hardware\tools\avr\utils on / type user (binmode,noumount)
C:\Users\RLOGIA~1\AppData\Local\Temp on /tmp type user (binmode,noumount)
c: on /c type user (binmode,noumount)
d: on /d type user (binmode,noumount)
e: on /e type user (binmode,noumount)
f: on /f type user (binmode,noumount)
r: on /r type user (binmode,noumount)

[matthijskooijman]

Hmm, I had hoped that would show R:\Windows as /, which would make stuff more consistent, but apparently it doesn't work like that. Still, the mount.exe coming from another version could mean that gcc's and mount's view on the filesystem are different...

[rlogiacco]

Would you be able to supply the correct mount.exe? I'm willing to help fixing this and it happens I do have spare time now...
In the meanwhile I've made a full clone of my test rig on drive D (again) to see if that makes any difference.

[matthijskooijman]

I don't know where to find a proper mount version. You could look at the scripts in https://github.com/arduino/toolchain-avr which are used to compile the (new version of the) toolchain. Perhaps you can run those scripts and compile mount and/or or find out what cygwin version was used exactly?

[rlogiacco]

Went through the scripts, no reference to the cygwin version whatsoever, just a mention in the readme it is required pointing directly to the cygwin site. I believe it just uses whatever version is installed on the building system... And mount doesn't seem to have an option to report it's own version... This seems to be a dead end for this troubleshooting path.

[matthijskooijman]

Hm. @ffissore, I think you built the avr toolchain, right? Do you know what cygwin version was used? Could you provide the mount.exe from the building system to @rlogiacco for debugging?

[wimjongman]

Ping!

[jantje]

Pong ;-)
Do you have this problem too Wim?

[wimjongman]

Yes. I recently picked up some coding again with the latest and the greatest but I found this as well.

[jantje]

your defeneatly not subscribed to my twitter. rofl https://twitter.com/Arduino_jantje

[jantje]

@ffissore
Do you have some input you can share?

[jfpoilpret]

Hi @cmaglie yes I work with Cosa, but AFAIK @mikaelpatel works only with Linux not Windows, he also does not use an IDE.

My purpose is to be able to use Cosa build system (itself based on Arduino-Makefile) and at the same time use Arduino Eclipse as the IDE (using Arduino IDE 1.5.8 behind the scenes).

Tha's what brought me here as:

• I originally setup cygwin for Cosa build (and that worked)
• but I was stopped with this issue when using Arduino Eclipse

Since then, I have setup MSYS2, to verify the toolchain created by @ffissore, which fixes the initial problem on Eclipse. And this is where I stand currently.

[jantje]

@jfpoilpret
It looks to me as if you can't load the cygwin.dll. Which is strange as the previous fix of @ffissore was to replace cygwin with mingw32. Did we revert back to cygwin?
It doesn't look so given your folder names.

[jfpoilpret]

I can confirm that the second zip provided by @ffissore is wrong: it fails both from an MSYS2 command-line and from Eclipse with the Arduino plugin.

So far, on one hand, I have reverted to the first provided MinGW-based zip as it seems to be OK from eclipse (I can build and upload as well); on the other hand, I keep cygwin-based toolchain in a special directory and I point the Cosa makefile there, hence I can still build in command line from Cygwin.

[ffissore]

@jantje can you please give it a run? Sorry to say that it works for me and that there are no cygwin dependencies.

[jantje]

@ffissore Sorry I don't have a windows machine at hand right now.
@rlogiacco Can you give it a try?

[AlirezaAbdiyan]

Has anyone been able to use arduino in Atmel studio or VS.net?

[rlogiacco]

I finally found some time to run a quick check and it seems that it is working as expected.

I even tried using a folder containing spaces and I got no issues.

To me this is definitely a solution.

@ffissore Just to let you know, in the new toolchain the share folder is missing, probably on purpose.

[rlogiacco]

@jantje @ffissore I'm not sure if this is related to the new toolchain or not, but while everything works fine with the Uno and the Pro Mini, I'm having issues uploading to a Micro which seems not resetting the COM.

Launching R:/Tools/ArduinoIDE/hardware/tools/avr/bin/avrdude -CR:/Tools/ArduinoIDE/hardware/tools/avr/etc/avrdude.conf -patmega32u4 -cavr109 -P COM4 -b57600 -D -Uflash:w:R:\Arduino\workspace\temp/Release/temp.hex:i 
Output:
avrdude: ser_open(): can't open device "\\.\COM4": Impossibile trovare il file specificato.
avrdude: ser_send(): write error: sorry no info avail

The issue doesn't occur when using the Arduino IDE 1.5.8 and I'm currently unable to verify if it's unrelated to the new toolchain, but somebody else might do a quick test.

I'm trying to upload a simple blink firmware.

[jantje]

@rlogiacco
The com port ".\COM4" is clearly wrong. I would expect that this is not build tool related.
As there is some preprocessing on the com port in the arduino eclipse plugin I made an issue there so we can make sure it is a Arduino IDE issue before bothering the arduino people.

[rlogiacco]

Cool thanks!

[ffissore]

@jantje can you then close this issue as solved? :)

[jantje]

Assuming this fix is part of the next release, I'm happy to close it.

[kjonas1]

Here is a quick fix. This fix is only requires two steps that are specific to the Arduino 1.5.8 IDE runtime: 1) copying the Cyg*.dll to a different folder location within the Arduino 1.5.8 IDE runtime, 2) copying the 'utils' folder from an older Arduino IDE runtime (i.e. I used v1.0.6, but other versions may work) into the Arduino 1.5.8 IDE runtime.

Details:

Step1)
First, from an older version (1.0.6) of the Arduino runtime IDE, I copied 'arduino-1.0.6\hardware\tools\avr\utils' folder into the 1.5.8 Arduino runtime IDE folder 'Arduino-1.5.8\hardware\tools\avr'. The 1.5.8 runtime originally doesn't have a utils folder under '...\hardware\tools\avr'; so this simply inserts a a new 'utils' folder (with the 1.0.6 runtime contents) under 'avr'. Note: The latest Eclipse (Juno) Arduino plugin, has its path pre-set to '...\hardware\tools\avr\utils\bin', so no config required in eclipse.

Step 2)
Lastly, I copied all the cyg*.dll in the root of Arduino-1.5.8 runtime, and pasted to 'Arduino-1.5.8\hardware\tools\avr\utils\bin'

Now all is happy. Compiling is successfully in both IDE's (Arduino native, and Eclipse Juno).

[kjonas1]

Well, I don't know why, but the above fixed quick working (perhaps after I performed a 'build clean'). I had to fold in the ming32 tool chain referenced above; now my builds (and uploads) are stable again. See below for updated version of my Step 2 (given above).
Crossing my fingers....

Details:

Step 2) Replace the toolchain with the mingw32 tool chain (referenced above --> 'avr-toochain-win32-3.4.4.zip') by unzipping 'avr-toolchain-win32-3.4.4.zip' to %WHEREEVER%\arduino-1.5.8\hardware\tools\avr\avr.

[GoGunner]

Before ya take offense, read first. As this has not been corrected I expand upon the previous messages with details. As I have said before under a different nym I think the Arduino plugin for Eclipse is great and is why I went through this. And hopefully others will find it the same. But those pesky indexing problems and that darn path.

There is no bug with GCC in this regard and you can even see it in the message below.
make all
Building file: ../slave_receiver.cpp
Starting C++ compile
"E:/arduino/arduino-1.6.0/hardware/tools/avr/bin/avr-g++" -c -g -Os -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=160 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -I"E:\arduino\arduino-1.6.0\hardware\arduino\avr\cores\arduino" -I"E:\arduino\arduino-1.6.0\hardware\arduino\avr\variants\standard" -I"E:\arduino\arduino-1.6.0\hardware\arduino\avr\libraries\Wire" -I"E:\arduino\arduino-1.6.0\hardware\arduino\avr\libraries\Wire\utility" -MMD -MP -MF"slave_receiver.cpp.d" -MT"slave_receiver.cpp.o" -D__IN_ECLIPSE__=1 -x c++ "../slave_receiver.cpp" -o "slave_receiver.cpp.o" -Wall
cygwin warning:
MS-DOS style path detected: E:\arduino\arduino-1.6.0\hardware\arduino\avr\cores\arduino
Preferred POSIX equivalent is: /cygdrive/e/arduino/arduino-1.6.0/hardware/arduino/avr/cores/arduino
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Finished building: ../slave_receiver.cpp

What is going on as previously stated is that it is VERY relative. The funny thing is what it is relative to on a Windoz system. One little DLL called "cygwin1.dll" if you just copy it to a directory which is on a seperate drive than the Arduino IDE directory being used, it work correctly. As it is a non-windows setup that is being forced to work on windoz, you may have to get creative. If for instance you are running on one large drive, just put it in the windows dir or create a bin dir off of the root dir. Add that dir to the path and make sure it is found before any other instance of it. ie your Arduino IDE dir

If you have Arduino setup or installed on the same drive as the windows dir, and your eclipse dir is on a different drive, well then you may need to get creative. heh Just put the bin dir off of the root of the eclipse drive.

You may need to uninstall the plugin and reinstall it if you start getting hundreds of errors. It happened to me the first time. Though it didn't happen after that even when monkeying around with the DLL's location while testing.

Below you will see snippets of the log. The first note and the last three lines of the snippet are what we will be interested in.

------- cygwin1.dll first found in windwos dir on different drive ------------------------------------

E:\CPP>E:\arduino-rduino-1.6.0\hardware\tools\avr\bin\avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-s
ections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=160 -DARDUINO_AVR_PRO -DARDUINO_ARCH_A
VR -D__IN_ECLIPSE__=1 -E -P -v -dD E:/CPP/Ard1.6/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Using built-in specs.
COLLECT_GCC=/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/avr-g++
Target: avr
Configured with: ../gcc-4.8.1/configure --enable-fixed-point --enable-languages=c,c++ --prefix=/cygdrive/c/jenkins/works
pace/toolchain-avr-3.4.3-windows/objdir --enable-long-long --disable-nls --disable-checking --disable-libssp --disable-l
ibada --disable-shared --with-avrlibc=yes --with-dwarf2 --disable-doc --target=avr
Thread model: single
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-g' '-Os' '-w' '-fno-exceptions' '-ffunction-sections' '-fdata-sections' '-fno-threadsafe-stat
ics' '-MMD' '-mmcu=atmega328p' '-D' 'F_CPU=16000000L' '-D' 'ARDUINO=160' '-D' 'ARDUINO_AVR_PRO' '-D' 'ARDUINO_ARCH_AVR'
'-D' '**IN_ECLIPSE**=1' '-E' '-P' '-v' '-dD'
 /cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../libexec/gcc/avr/4.8.1/cc1plus.exe -E -quiet -v -P -imultili
b avr5 -iprefix /cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/ -MMD spec.d -D F_CPU=1600
0000L -D ARDUINO=160 -D ARDUINO_AVR_PRO -D ARDUINO_ARCH_AVR -D **IN_ECLIPSE**=1 E:/CPP/Ard1.6/.metadata/.plugins/org.ecl
ipse.cdt.managedbuilder.core/spec.C -mmcu=atmega328p -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threads
afe-statics -g -fworking-directory -Os -fno-rtti -fno-enforce-eh-specs -fno-exceptions -dD
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../.
./avr/include/c++/4.8.1"
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../.
./avr/include/c++/4.8.1/avr/avr5"
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../.
./avr/include/c++/4.8.1/backward"
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../.
./avr/sys-include"
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.
8.1/../../../../avr/include/c++/4.8.1"
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.
8.1/../../../../avr/include/c++/4.8.1/avr/avr5"
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.
8.1/../../../../avr/include/c++/4.8.1/backward"
ignoring duplicate directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.
1/include"
ignoring duplicate directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.
1/include-fixed"
ignoring nonexistent directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.
8.1/../../../../avr/sys-include"
ignoring duplicate directory "/cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.
1/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include
 /cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include-fixed
 /cygdrive/e/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include

End of search list.

---------------- cygwin1.dll first found in current dir same drive -------------------------------

E:\CPP>E:\arduino-rduino-1.6.0\hardware\tools\avr\bin\avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-s
ections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=160 -DARDUINO_AVR_PRO -DARDUINO_ARCH_A
VR -D__IN_ECLIPSE__=1 -E -P -v -dD E:/CPP/Ard1.6/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Using built-in specs.
COLLECT_GCC=/arduino/-rduino-1.6.0/hardware/tools/avr/bin/avr-g++
Target: avr
Configured with: ../gcc-4.8.1/configure --enable-fixed-point --enable-languages=c,c++ --prefix=/cygdrive/c/jenkins/works
pace/toolchain-avr-3.4.3-windows/objdir --enable-long-long --disable-nls --disable-checking --disable-libssp --disable-l
ibada --disable-shared --with-avrlibc=yes --with-dwarf2 --disable-doc --target=avr
Thread model: single
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-g' '-Os' '-w' '-fno-exceptions' '-ffunction-sections' '-fdata-sections' '-fno-threadsafe-stat
ics' '-MMD' '-mmcu=atmega328p' '-D' 'F_CPU=16000000L' '-D' 'ARDUINO=160' '-D' 'ARDUINO_AVR_PRO' '-D' 'ARDUINO_ARCH_AVR'
'-D' '**IN_ECLIPSE**=1' '-E' '-P' '-v' '-dD'
 /arduino/-rduino-1.6.0/hardware/tools/avr/bin/../libexec/gcc/avr/4.8.1/cc1plus.exe -E -quiet -v -P -imultilib avr5 -ipr
efix /arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/ -MMD spec.d -D F_CPU=16000000L -D ARDUINO=160 -
D ARDUINO_AVR_PRO -D ARDUINO_ARCH_AVR -D **IN_ECLIPSE**=1 E:/CPP/Ard1.6/.metadata/.plugins/org.eclipse.cdt.managedbuilde
r.core/spec.C -mmcu=atmega328p -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -g -fworki
ng-directory -Os -fno-rtti -fno-enforce-eh-specs -fno-exceptions -dD
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/inclu
de/c++/4.8.1"
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/inclu
de/c++/4.8.1/avr/avr5"
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/inclu
de/c++/4.8.1/backward"
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/sys-i
nclude"
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../.
./../avr/include/c++/4.8.1"
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../.
./../avr/include/c++/4.8.1/avr/avr5"
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../.
./../avr/include/c++/4.8.1/backward"
ignoring duplicate directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/include"
ignoring duplicate directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/include-f
ixed"
ignoring nonexistent directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../.
./../avr/sys-include"
ignoring duplicate directory "/arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../
../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include
 /arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include-fixed
 /arduino/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include

End of search list.

--------------- cygwin1.dll first found in arduinoxxx\bin --------------------------

E:\CPP>E:\arduino-rduino-1.6.0\hardware\tools\avr\bin\avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-s
ections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=160 -DARDUINO_AVR_PRO -DARDUINO_ARCH_A
VR -D__IN_ECLIPSE__=1 -E -P -v -dD E:/CPP/Ard1.6/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Using built-in specs.
COLLECT_GCC=/hardware/tools/avr/bin/avr-g++
Target: avr
Configured with: ../gcc-4.8.1/configure --enable-fixed-point --enable-languages=c,c++ --prefix=/cygdrive/c/jenkins/works
pace/toolchain-avr-3.4.3-windows/objdir --enable-long-long --disable-nls --disable-checking --disable-libssp --disable-l
ibada --disable-shared --with-avrlibc=yes --with-dwarf2 --disable-doc --target=avr
Thread model: single
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-g' '-Os' '-w' '-fno-exceptions' '-ffunction-sections' '-fdata-sections' '-fno-threadsafe-stat
ics' '-MMD' '-mmcu=atmega328p' '-D' 'F_CPU=16000000L' '-D' 'ARDUINO=160' '-D' 'ARDUINO_AVR_PRO' '-D' 'ARDUINO_ARCH_AVR'
'-D' '**IN_ECLIPSE**=1' '-E' '-P' '-v' '-dD'
 /hardware/tools/avr/bin/../libexec/gcc/avr/4.8.1/cc1plus.exe -E -quiet -v -P -imultilib avr5 -iprefix /hardware/tools/a
vr/bin/../lib/gcc/avr/4.8.1/ -MMD spec.d -D F_CPU=16000000L -D ARDUINO=160 -D ARDUINO_AVR_PRO -D ARDUINO_ARCH_AVR -D **I
N_ECLIPSE**=1 E:/CPP/Ard1.6/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -mmcu=atmega328p -w -fno-excep
tions -ffunction-sections -fdata-sections -fno-threadsafe-statics -g -fworking-directory -Os -fno-rtti -fno-enforce-eh-s
pecs -fno-exceptions -dD
ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4.8.1"
ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4.8.1/avr/avr5"

ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4.8.1/backward"

ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/sys-include"
ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4
.8.1"
ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4
.8.1/avr/avr5"
ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4
.8.1/backward"
ignoring duplicate directory "/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/include"
ignoring duplicate directory "/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/include-fixed"
ignoring nonexistent directory "/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr/sys-include"
ignoring duplicate directory "/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include
 /hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include-fixed
 /hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include

End of search list.

----------- cygwin1.dll first found in arduinoxxx -----------------------------------

E:\CPP>E:\arduino-rduino-1.6.0\hardware\tools\avr\bin\avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-s
ections -fno-threadsafe-statics -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=160 -DARDUINO_AVR_PRO -DARDUINO_ARCH_A
VR -D__IN_ECLIPSE__=1 -E -P -v -dD E:/CPP/Ard1.6/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Using built-in specs.
COLLECT_GCC=/-rduino-1.6.0/hardware/tools/avr/bin/avr-g++
Target: avr
Configured with: ../gcc-4.8.1/configure --enable-fixed-point --enable-languages=c,c++ --prefix=/cygdrive/c/jenkins/works
pace/toolchain-avr-3.4.3-windows/objdir --enable-long-long --disable-nls --disable-checking --disable-libssp --disable-l
ibada --disable-shared --with-avrlibc=yes --with-dwarf2 --disable-doc --target=avr
Thread model: single
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-c' '-g' '-Os' '-w' '-fno-exceptions' '-ffunction-sections' '-fdata-sections' '-fno-threadsafe-stat
ics' '-MMD' '-mmcu=atmega328p' '-D' 'F_CPU=16000000L' '-D' 'ARDUINO=160' '-D' 'ARDUINO_AVR_PRO' '-D' 'ARDUINO_ARCH_AVR'
'-D' '**IN_ECLIPSE**=1' '-E' '-P' '-v' '-dD'
 /-rduino-1.6.0/hardware/tools/avr/bin/../libexec/gcc/avr/4.8.1/cc1plus.exe -E -quiet -v -P -imultilib avr5 -iprefix /-r
duino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/ -MMD spec.d -D F_CPU=16000000L -D ARDUINO=160 -D ARDUINO_AVR_PR
O -D ARDUINO_ARCH_AVR -D **IN_ECLIPSE**=1 E:/CPP/Ard1.6/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -m
mcu=atmega328p -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -g -fworking-directory -Os
 -fno-rtti -fno-enforce-eh-specs -fno-exceptions -dD
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4
.8.1"
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4
.8.1/avr/avr5"
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include/c++/4
.8.1/backward"
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/sys-include"
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr
/include/c++/4.8.1"
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr
/include/c++/4.8.1/avr/avr5"
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr
/include/c++/4.8.1/backward"
ignoring duplicate directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/include"
ignoring duplicate directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/include-fixed"
ignoring nonexistent directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr
/sys-include"
ignoring duplicate directory "/-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/../../lib/gcc/avr/4.8.1/../../../../avr/i
nclude"
#include "..." search starts here:
#include <...> search starts here:
 /-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include
 /-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/include-fixed
 /-rduino-1.6.0/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/include

End of search list.

Corrected:

Environment was correct:

Preprocessor wasn't picking it up though.

Oh and ignore the -rduino vs the \Arduino in the picts, I just happen to finalize everything before taking pics of the Eclipse plugin properties.

[jantje]

@ffissore
Is this fix part of 1.6? I see nothing in the release note and I see that 1.6.1 does talk about a tool chain change.
I also see cygwin.dll is still part of the delivery.

[GoGunner]

No, it wasn't fixed that I can tell. That was me trying to use the information on hand to find a solution. 1.6 with GCC 4.8.1 back until 1.54 with GCC 4.3.2 What you could do is have the plugin just copy the dll from arduino ide location to the plugin area of eclipse. I tried to run regsrv32 on it but not a valid dll type for to succeed. The only way I found it to work is put in the place that it was being called from, or simply put it my windoz dir as I have a separate drive for my linux style coding.

[ffissore]

No, new toolchain didn't make it for 1.6. #2568 has been merged right after and the new toolchain is now part of the nightly build and will be part of 1.6.1

[jantje]

any idea on the expected release date of 1.6.1?

[GoGunner]

I just tested the nightly without any alterations as previously described and it seems we are back to what was expected at 1.54

[jantje]

@GoGunner
I understand your remark as "fixed in the nightly"
Did I understand that correctly?

[ffissore]

@jantje soon

[jantje]

@ffissore :-)

[GoGunner]

@jantje Yes, it appears so. Or at least more windoz friendly as I think the other was ok just not windoz friendly.

[jantje]

I'm really glad @ffissore fixed it and it becomes part of 6.1.