maynardGK

This is a newer feature of IDL which is not in GDL (and wont be there anytime soon).

My compiler left that as a warning but I got rid of the message by replacing NULL with 0 as return values in gdlpython.cpp, see #753

Right, it appears to be libxdr.a and libxdr.dll.a where the conflict is. hdf4 uses types.h, xdr.h from /include (no rpc) ``` :: Proceed with installation? [Y/n] y (1/1) checking keys...

Ok I think that will work with a change in CMakeModules/FindXdr.cmake: find_library(XDR_LIBRARY NAMES bsdxdr xdr) That works to build. My system isn't picking up the /bin directory libraries as it...

> You might need to add your python path to the PATH variable. In that last example I built GDL from my usual cmake command, without any python. Excluding python...

I don't think GDL has been built for ver 7, there is at least one issue with the source code to acomodate it https://github.com/gnudatalanguage/gdl/issues/521 was a short stab at using...

Another odd behavior of concatenation: "&&" should be interpreted(?) as just "&" but is not: ```` GDL> resu2a=FILE_WHICH('../src/', filetest) & print,resu2a ../src/gdl GDL> resu2a=FILE_WHICH('../src/', filetest) & & print,resu2a ../src/gdl GDL>...

At some point there was a need to improve the find of a package, and remember it was cmake 2.28 or so for a long time - what cmake has...