0

I am trying to use Eclipse CDT with the Cygwin GCC toolchain in order to read in some images using png++. I have installed the png++ headers (I tried both 0.2.5 and 0.2.7) in my Cygwin, and it compiles fine using the external builder settings with make, but for some reason the editor underlines "image" from png::image in the very simple code:

#include <png++/png.hpp>

int main( int argc, char* argv[]){
    png::image<png::gray_pixel> t(128,128);
    return 1;
}

And gives the error:

Invalid template arguments.

I looked around a bit for this error, and it seems for other people it was caused by not having GCC set to use C++11 (such as Invalid template arguments on map std::map< std::string, Stock*> &stocks), but I do not think that is an issue with me, since I have my "CDT GCC Built-in Compiler Settings Cygwin" provider command set to:

${COMMAND} ${FLAGS} -E -P -v -dD -std=c++11 "${INPUTS}"

And the line std::normal_distribution<double> distribution(5.0,2.0); does not give an error.

I can remove the error underline by turning off "Invalid template argument" under the project properties -> C/C++ General -> Code Analysis, but the problem is deeper than that, as none of the auto-completes will work for the object of type png::image, and if I try and use it in a function, for example:

void pngTest(png::image<png::gray_pixel> im, int other) {}

it gives the error: Invalid arguments ' Candidates are: void pngTest(?, int) '

So it seems it does not resolve the type at all. What might be causing this?

Community
  • 1
  • 1
QueueUnderflow
  • 43
  • 1
  • 6
  • 1
    Advice -- The Eclipse IDE is not a C++ compiler, and the C++ language is complex. I know that IDE developers try to do their best in keeping up with language rules, but it is a daunting task. Your code has no compiler errors, so it is valid. Therefore you can either spend time trying to fix IDE problems (and get into the plugin business), or spend time developing your program. – PaulMcKenzie Feb 08 '15 at 20:20
  • @PaulMcKenzie - so true... Eclispe and its plugins are broken with Android's NDK R10d. It won't produce APKs. I now have to do everything from the command line using `ndk-build`, `ant` (which work fine) and push to the device using `adb`. See [Eclipse/ADT plugin cannot locate symbols for r10d NDK](https://code.google.com/p/android/issues/detail?id=97023). What a waste of time.... – jww Feb 08 '15 at 21:45
  • So if this is an eclipse bug then yeah, not much can be done I guess, although that would surprise me a bit because png++ is just header files and the image class is not particularly complex. I was just wondering if it was something in the eclipse settings that could be easily fixed, but if not then I will just live with it. – QueueUnderflow Feb 08 '15 at 21:57
  • Actually seems that it wasn't an eclipse problem, see my answer below – QueueUnderflow Feb 09 '15 at 00:04

1 Answers1

0

Turns out this was not actually a bug with Eclipse parsing, but an incompatibility with Cygwin style symlinks. In png++'s png.hpp and types.hpp it includes png.h from libpng, but in Cygwin png.h (in /usr/include) is a Cygwin style symlink to the current libpng (in my case the file contained the text: !<symlink>libpng16/png.h).

So Eclipse could not resolve this include, even though Cygwin's GCC could, and it was making the typedefs in types.hpp not resolve correctly. This is why I was getting an invalid template arguments error in eclipse, png::gray_pixel was not a valid type. I noticed this when I put <int> instead and it no longer gave an error. So that was the problem.

I changed the include paths from png.h to libpng16/png.h in both png.hpp and types.hpp

and now everything in eclipse is resolving correctly after a right click on the project -> index -> rebuild. Alternatively you could symlink png.h, pngconf.h, and pnglibconf.h in /usr/include to the appropriate libpng subfolder using the windows mklink command and remove the Cygwin style symlinks.

If anyone knows a way for Eclipse to work seamlessly with Cygwin symlinks then post here and I will accept that as the answer, since obviously that is a little better than this hacky fix.

Thank you guys for the comments, but it seems thankfully that this time it was not an Eclipse issue.

QueueUnderflow
  • 43
  • 1
  • 6