GDL - GNU Data Language

GDL is a free/libre/open source incremental compiler compatible with IDL (Interactive Data Language) and to some extent with PV-WAVE. Together with its library routines it serves as a tool for data analysis and visualization in such disciplines as astronomy, geosciences and medical imaging. GDL development had been started by Marc Schellens back in early noughties and has since continued with help of a team of maintainers, developers, packagers and thanks to feedback from users.

IDL is a registered trademark of Harris Geospatial Solutions. PV-WAVE is a product of Rogue Wave Software.


GDL is a domain-specific programming language and a data analysis environment. As a language, it is dynamically-typed, array-oriented, vectorised and has object-oriented programming capabilities. GDL library routines handle numerical calculations, data visualisation, signal/image processing, interaction with host OS and data input/output. GDL supports several data formats such as netCDF, HDF4, HDF5, GRIB, PNG, TIFF, DICOM, etc. Graphical output is handled by X11, PostScript, SVG or z-buffer terminals, the last one allowing output graphics (plots) to be saved in a variety of raster graphics formats. GDL features integrated debugging facilities. The built-in widget functionality enables development of GUI-based software. GDL has also a Python bridge (Python code can be called from GDL; GDL can be compiled as a Python module). Development and maintenance of GDL is carried out targeting Linux, BSD, OSX and Windows (MinGW, Cygwin).

GDL is invoked just by typing gdl but see gdl -h as it has a number of commandline options. GDL may be known as gnudl or gnudatalanguage on some operating systems.

Other open-source numerical data analysis tools similar to GDL include SciPy, GNU Octave, Scilab, PDL, NCL, R, Yorick.

Getting GDL



Check the WIKI for (transient) alerts.


Packaged versions of GDL are available for several Linux distributions, BSD and Mac OS X. Please note that several features of GDL depend on compile-time configuration, and might not be available in pre-built or pre-configured packages.

GDL has numerous dependencies, most of the optional but highly recommended if you want it to be areally useful tool.

  • readline mandatory. For easy command line editing, recalling, history.

  • [n]curses mandatory. Terminal management.

  • zlib mandatory. compressed file access.

  • GSL mandatory, for many math functions.

  • OpenMP optional, but speed will suffer if not present

  • Magick++ / GraphicsMagick optional, but don’t you want to read/write many image formats?

  • wxWidgets mandatory unless you do not want graphic outputs and widgets?

  • Xlib/X11 not used unless you explictly ask for it (replaced by wxWidgets for sake of compatibility on Windows, linux and MacOSX.

  • netCDF optional, but useful for reading this kind of data.

  • HDF4 optional, but useful for reading this kind of data.

  • HDF5 optional, but useful for reading this kind of data.

  • FFTW optional, but don’t you need a fast fft at times?

  • PROJ optional but forget about mapping capabilities if absent.

  • Shapelib optional but forget about mapping capabilities if absent.

  • Expat optional but helps implement IDLffXMLSAX parser objects.

  • MPI optional but provides clustering facilities.

  • Python/NumPy optional but add python bridge and jupyter notebook.

  • udunits optional, units conversion

  • Eigen optional but provides inordinate speed enhancements…

  • ecCodes optional, for GRIB support.

  • GLPK optional, provides the SIMPLEX command.

Besides, for optimal use (speed mainly), GDL incorporates slightly edited code of

Build-time dependencies

Build and test automation is carried out using CMake.

GDL interpreter has been developed using ANTLR v2 but unless you want to change the grammar (*.g files) you don’t need ANTLR. All relevant ANTLR files are included in the source tree.

Support, feedback and contributions

Your comments are welcome! Let us know what you use GDL for. Or if you don’t, why not. Which functionality are you missing/would appreciate most for coming versions. Please use the github issue-tracking system to report bugs, complaints, suggestions and comments.

Code enhancements in the form of pull requests are very welcome! Note that contributions can be made in C++, IDL/GDL or Python, as well as by providing enhancements and extensions of the README files, diagnostic messages, etc.

Among the major challenges GDL development is facing currently, there are:

  • enhancing test coverage by writing test programs in GDL

  • streamlining development and maintenance of GDL reference docs and examples (using the Jupyter kernel?)

  • bringing in into the team the needed know-how to address the backlog of ANTLR-related issues

  • increasing presence within and interoperability with the Python ecosystem, including adding support for Python 3 (calling GDL from Python 2 and calling Python 2 from GDL is already implemented!)

Help welcome!

Information resources

GDL does not maintain a proper documentation: as GDL is aimed as a drop-in replacement for IDL, resources for IDL constitute the valuable sources of information for GDL users as well. GDL MUST behave (at least) as IDL, and any discrepancy should be reported by opening an issue. Conversely, the GDL issues and discussion forum on GitHub are not the good place for beginners to ask for advice on how to use IDL (or GDL). Use the forum below. IDL freely available resources include:

There are several open source packages compatible or interoperable with GDL, including:

Alain Coulais maintains the GDL-announces mailing list.

There have been quite some mentions of GDL in scientific literature which also provide example use cases. The Coulais et al. papers from the ADASS conferences are the best way to cite GDL as of now.


GDL development had been carried out at SourceForge in years 2003-2018 - thank you!