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 notifications@github.com 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