Rcpp+Eclipse on Mac OS X - eclipse

I am trying to get started using Rccp and decided to use Eclipse as a development environment since I already use StatEt for R. I am having trouble getting even a simple program to compile and run though, and would appreciate some help!
Briefly I tried to follow the instructions on the blog: http://blog.fellstat.com/?p=170 exactly for setting up Rcpp, RInside and Eclipse, and for the example program. I am running on Mountain Lion, and installed g++ using the command line options in XCode. I think I've faithfully followed all the steps in the blog, but cannot get the program to compile. I think the problem is in the way the header files are included, as indicated from the snippet of the output below. As far as I can tell, line 52 of /usr/include/c++/4.2.1/cstring is an include statement for <string.h> and the compiler includes Rccp/include/string.h instead of the string.h from std that is found earlier on the include path.
I am a novice in C++ so I'd really appreciate some pointers on how to proceed.
-Krishna
16:22:38 **** Incremental Build of configuration Debug for project MyTestRCppPackage ****
Info: Internal Builder is used for build
g++ -DINSIDE -I/Library/Frameworks/R.framework/Versions/2.15/Resources/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include -O0 -g3 -Wall -c -fmessage-length=0 -arch x86_64 -v -o src/main.o ../src/main.cpp
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/cc1plus -quiet -v -I/Library/Frameworks/R.framework/Versions/2.15/Resources/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include -imultilib x86_64 -iprefix /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/ -dD -D__DYNAMIC__ -DINSIDE ../src/main.cpp -fPIC -quiet -dumpbase main.cpp -mmacosx-version-min=10.8.3 -m64 -mtune=core2 -auxbase-strip src/main.o -g3 -O0 -Wall -version -fmessage-length=0 -D__private_extern__=extern -o /var/folders/hc/vqp48jt56_v332kc3dqyf5780000gn/T//ccqdmOKI.s
ignoring nonexistent directory "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin11/x86_64"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
#include "..." search starts here:
#include <...> search starts here:
/Library/Frameworks/R.framework/Versions/2.15/Resources/include
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include
/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/include
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) (i686-apple-darwin11)
compiled by GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=65536
Compiler executable checksum: b37fef824b01c0a99fb2679acf3b04f1
In file included from /usr/include/c++/4.2.1/cstring:52,
from /usr/include/c++/4.2.1/bits/stl_algobase.h:66,
from /usr/include/c++/4.2.1/memory:53,
from /usr/include/c++/4.2.1/tr1/hashtable:56,
from /usr/include/c++/4.2.1/tr1/unordered_map:37,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/platform/compiler.h:158,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/RcppCommon.h:26,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp.h:27,
from ../src/main.cpp:8:
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: 'internal' has not been declared
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: typedef name may not be a nested-name-specifier
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: expected ';' before '<' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:65: error: expected `)' before 'charsxp'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:70: error: expected ',' or '...' before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: expected unqualified-id before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: expected ',' or '...' before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: 'Rcpp::String::String()' cannot be overloaded
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:55: error: with 'Rcpp::String::String()'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:85: error: 'Rcpp::String::String(int)' cannot be overloaded
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:70: error: with 'Rcpp::String::String(int)'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:88: error: expected `)' before 'x'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:89: error: expected `)' before 'x'

There are two entirely separate issues here:
Get all you need for Rcpp installed. OS X aspects should be documented on the relevant page maintained by Simon. If you have the tools, and have Rcpp install, then you should be able to do cppFunction('double nPi(int x) { return x*M_PI; }') which is uses functions supplied with Rcpp to create a callable C++ functions accessible to you as nPi() -- and nPi(2) should return a value.
Your choice of IDE and its settings. This is has little to do with 1. apart from requiring it to work to.
So I would work on 1. and see if I got that sorted out first, and only then turn to 2.

To summarize, the issue I faced was that include files in Rcpp with the sames names as those in std were in conflict. In particular, string.h from Rcpp was being included at a point where string.h from std was the right choice, and, as far as I could tell, this was due to the fact that paths specified via the -I directive are searched prior to the default paths.
I tried many different alternatives to solve this, including removing and re-installing XCode and the associated Command Line tools, as well as installing another g++ compiler using macports. None of these resolved the issue. I then used the -idirafter directive instead of the -I directive for the search path for include files for Rcpp and R. I got this hint from gcc include order broken?. This worked since these directories are now searched after the default paths. This precludes (at least so far!) the possibility that string.h from std and string.h from Rcpp come into conflict.
To get step 5 of http://blog.fellstat.com/?p=170 to work I had to set the -idirafter paths in PKG_CPPFLAGS in the file Makevars.
Thanks to everyone for your suggestions.

You simply have to remove include
/Library/Frameworks/R.framework/Resources/library/Rcpp/include/Rcpp
because it is:
unnecessary, as all R imports are in form <Rcpp/XXX>
causes this issue, as compiler looks for string.h in Rcpp directory (when it shouldn't).

Related

Eclipse CDT parser support for c++14

Good old disconnect between what the compiler deems valid and what the IDE thinks... Before you introduce duplicate questions / answers, I must stress that everything available on the issue here and elsewhere I have already tried and distilled to this setup:
install latest eclipse CDT - Oxygen 4.7.2 / build id 20171218-0600
gcc 6.1 only compiler visible in system path - defaults to c++14 standard without the need for explicit -std flag
Checking the log for compiler settings discovery, it's configured correctly for C++14:
03:51:39 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
g++ -E -P -v -dD C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-6.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/lib -L/c/mingw610/prerequisites/x86_64-zlib-static/lib -L/c/mingw610/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 6.1.0 (x86_64-posix-seh, Built by MinGW-W64 project)
COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-shared-libgcc' '-mtune=core2' '-march=nocona'
C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/6.1.0/cc1plus.exe -E -quiet -v -P -iprefix C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/ -D_REENTRANT C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -mtune=core2 -march=nocona -dD
#define __STDC__ 1
#define __cplusplus 201402L
(etc)
The following snippet compiles (with unused variable warning but nonetheless), but eclipse highlights issues with resolving test in int main:
auto test (auto N) {return N;}
int main () {
auto z = test( 3U );
return 0;
}
The parser log gives:
Unresolved names:
Attempt to use symbol failed: test in file ...
The IDE shows this in problems:
Invalid arguments '
Candidates are:
? test(?)
'
For all intents and purposes eclipse is in fact seeing the correct gcc binary, and is using the correct c++ standard, but still not conforming to the compiler per evidence above (unless I missed something?).
Any ideas how to make eclipse behave with syntax parsing given it's already got the right c++ standard version?
I get the feeling it's an issue with the indexer rather than the parser, since it has no trouble figuring out the number of arguments or the declaration but can't seem to make sense of functions with auto return type that depends on an auto-typed argument.
UPDATE
It may be related to this bug (looks to be fixed) and this followup bug (still ongoing, test case given is similar to mine).
However, this version of test does not give me problems, so I'm unsure if it's the same bug or something else...
template< typename T > auto test (T N) {return N;}
auto in the parameter type of a function (as opposed to a lambda) is not standard C++14.
It's supported by the Concepts TS (which is supported by GCC >= 6 with the -fconcepts flag), and accepted by GCC >= 4.9 even without -fconcepts as an extension, but it's not standard. (It may become standard in C++20, along with some other parts of the Concepts TS.)
For example, here's what Clang (which does not support this extension) says about your code in C++14 mode:
test.cpp:1:12: error: 'auto' not allowed in function prototype
auto test (auto N) {return N;}
^~~~
Eclipse CDT does not currently implement this extension either. I filed bug 532085 to track adding support for it; contributions are welcome!

Compiling with icc and MAGMAmic cannot find "complex" system file

I am trying to compile a source file with icc compiler and MAGMAmic library. However I get the following error:
icc -c -o direct.o direct.c -O3 -openmp -DADD_ -Wall -DHAVE_MIC -I/opt/intel/mic/coi/include -I/usr/include/intel-coi -I/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/ipp/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/tbb/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/daal/include -I/home/dslavchev/install/magmamic-1.4.0/include -I/home/dslavchev/install/magmamic-1.4.0/contol
icc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
In file included from /home/dslavchev/install/magmamic-1.4.0/include/magma_types.h(134),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas_z.h(17),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas.h(12),
from /home/dslavchev/install/magmamic-1.4.0/include/magma.h(17),
from direct.c(21):
/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex(30): catastrophic error: cannot open source file "complex"
#include_next <complex>
^
The MAGMAmic library has compiled correctly and I can run it's test ok.
I have looked at the way testing_dgesv_mic.cpp example compiles and used the same includes and link, however in my case I get the above error.
I have added the following in my .bashrc file in order to get the Intel compilers' and libraries' enviromental variables:
#for MAGMA mic
export MAGMA_PATH=/home/dslavchev/install/magmamic-1.4.0
source /opt/intel/bin/compilervars.sh intel64
source /opt/intel/mkl/bin/mklvars.sh intel64
Any ideas what might cause icc to be unable to include the "complex" file?
The file complex really exists in "/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex"
icc vesrion is:
[dslavchev#sl051 results]$ icc -v
icc version 17.0.2 (gcc version 4.4.7 compatibility)
magmamic version is magmamic-1.4.0
EDIT: Removed unnecessary code comment
EDIT2: Added version info.
MAGMAmic is a C++ library and it cannot be used with C code directly.
When icc detects that you want to compile .c++ file it automatically switches to icpc (Intel C++ compiler) which in turn results in the above error.
Solution: Either switch to icpc or rename your files to .c++
This question was answered by mark on the MAGMA forums. Link:
http://icl.cs.utk.edu/magma/forum/viewtopic.php?f=2&t=1587&p=4442#p4442

STM32 Eclipse + ARM GNU toolchain error linker

I use Eclipse + ARM plugin to build my projects. When I needed to use in my project the StemWin library, I configured my IDE to use external library.
I set
Preferences -> C/C++ General -> Paths and Symbols
I added in "Library Paths" the link to my folder includes library.
I also added the name of my library in tab "Library".
I checked the settings in the compiler tab and I ascertained all should be good.
When I tried to build my project I got an error from linker:
cannot find -lMyLib.a Hello C/C++ Problem
I double checked the name of my library and link, all are correct. This is the output of my linker:
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib"
-T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,
-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" -lMyLib.a
What should I do from here?
I faced the same problem before.
-l:STemWin526_CM4_GCC.a
-L"C:\Edu_Workspace\STM32F4\stm32f4_bsp_template\Drivers\Middlewares\ST\STemWin\Lib"
Above are my working settings.
With -l:<archive file name> the colon : is important for archive file linking.
And -L will contain library path.
Also for stemwin make sure to compile with hardware floating point
-mfloat-abi=hard -mfpu=fpv4-sp-d16
the convention for the -l option of the linker (say you give -lMyLib.a as a linker option) is to search for a library file with "lib" prepended to the given name and .a (or .so) appended, i.e. your command line searches for a file libMyLib.a.{a,so} which is probably not how it's named.
Either you rename your library according to this convention or give it to the linker command line omitting -l (provided your IDE allows you to do so).
Looks like the problem is in -lMyLib.a which means you're trying to link a static library as a dynamic one.
To link a static lib you have to use its path as with ordinary .o files: ... /path/to/MyLib.a
and the resulting command line should look something like
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib" -T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" /path/to/MyLib.a
UPDATE:
Although it might fix the issue, turns out it's not true:
-llibrary
-l library
...
Normally the files found this way are library files—archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.
(https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html)

Issues with g++ and Eclipse on Linux - unresolved symbols

I am running Ubuntu 64bit version, and downloaded the latest 64bit Eclipse.
Installed g++ along with build-essential. Tested g++ to make sure it works from terminal, and it works fine.
alex#ubuntu:~/Desktop$ g++ test.cpp -o test
alex#ubuntu:~/Desktop$ ./test
Hello World!alex#ubuntu:~/Desktop$
However, trying to build simple C++ Hello Word project(one of the default projects that comes with Eclipse), I am getting error.
Description Resource Path Location Type
Program "g++" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Builtin Compiler Settings] options C/C++ Scanner Discovery Problem
I have added Environment variable named g++ with value /usr/bin/g++ and the above error went away, however, now I am getting unresolved errors, though project compiles and in the Console shows !!!Hello World!!!
Description Resource Path Location Type
Symbol 'endl' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'cout' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'std' could not be resolved test_hello.cpp /test_hello/src line 10 Semantic Error
Have I correctly entered Environmental variable ?? How can I get fix the "unresolved" error ?? Thanks !
When compiling there are two important things to consider:
1.) Is my path up-to-date with executables?
2.) Is my library path correct?
It appears you satisfy 1.) but not 2.)
The unresolved symbol error means that Eclipse cannot find your library via LD_LIBRARY_PATH or some other medium. It's attempting to locate the standard compiled C++ library.
How did you install g++?
Kindly do this and post the results:
Project > Properties > C/C++ Build > Environment
If everything there appears nominal, you can try
/sbin/ldconfig
which should hopefully re-parse your system library paths and might update your environment.

Eclipse compiles correctly but shows error in 'Problems' view

The console output is:
**** Build of configuration Release for project Timertestnew ****
make all
Building file: ../main.cpp
Invoking: AVR C++ Compiler
avr-g++ -I"G:\arduino-1.0\hardware\arduino\cores\arduino" -DARDUINO=100 -Wall -Os -fpack-struct -fshort-enums -funsigned-char -funsigned-bitfields -fno-exceptions -mmcu=atmega328p -DF_CPU=16000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "../main.cpp"
Finished building: ../main.cpp
Building target: Timertestnew.elf
Invoking: AVR C++ Linker
avr-gcc --cref -s -Os -o"Timertestnew.elf" ./main.o -lArduinoCore -lm -Wl,-Map,Timertestnew.map,--cref -L"C:\Users\Akhil\workspace\Timertestnew" -mmcu=atmega328p
Finished building target: Timertestnew.elf
Create Flash image (ihex format)
avr-objcopy -R .eeprom -O ihex Timertestnew.elf "Timertestnew.hex"
Finished building: Timertestnew.hex
Invoking: Print Size
avr-size --format=avr --mcu=atmega328p Timertestnew.elf
AVR Memory Usage
----------------
Device: atmega328p
Program: 620 bytes (1.9% Full)
(.text + .data + .bootloader)
Data: 9 bytes (0.4% Full)
(.data + .bss + .noinit)
Finished building: sizedummy
**** Build Finished ****
The 'Problem' view output is:
Description Resource Path Location Type
Symbol 'EEARH' could not be resolved main.cpp /Timertestnew line 15 Semantic Error
Is it possible that eclipse ide is mistakenly showing this error while it compiles it fine?
How can I fix this?
Try to delete that problem marker from the problems view and rebuild your project (entirely, not just an incremental). If that fixes the issue, than it was simply an inconsistent state of the compiler.
However, if it does not fix the problem, then it is possible that the Eclipse editor uses a different parser (for content assist, etc.), that cannot handle something your compiler can. For this case, I would look around the C/C++ editor preferences related to errors, maybe it is turnable off (however, I don't program C/C++, so I cannot tell you what to look for).
The avr-gcc compiler uses its -mmcu command line argument to determine which IO header file to include (and therefore symbolic register definition including the EEARH EEPROM high address register being reported). Documentation here.
Eclipse may not be aware of this 'backdoor' preprocessor symbol definition (as it probably is using a different compiler for problem detection). From the console output it looks like the IO header file you need is: avr/iom328p.h which is included when the __AVR_ATmega328P__ preprocessor symbol is defined (see here). If you provide this symbol to Eclipse it should cause its compiler to pick up the correct file and define the relevant registers.