Comment installer GDL (0.8.11) sous GNU/Linux

La version initiale de ce document a été rédigée début Janvier 2006. Elle concernait alors la compilation de la version 0.8.11 de GDL sous GNU/Linux. Depuis, la version 0.8.12 (en CVS et en RPM, mais pas en TGZ) puis les versions 0.9-pre (1 a 4) sont sorties, qui corrigent de multiples petits problèmes (architecture x86_64, Mac OS X sous plateforme Intel, petits et gros bugs divers (contour, TV, ...)) et ajoutent plusieurs fonctionnalités réclamées (/f77unformatted, Save/Restore, ...). Il est vivement conseillé de partir de la dernière version en téléchargement (*.tgz) (et donc de transposer le document !) et d'y appliquer ensuite le CVS. N'hésitez pas à me signaler tout succès ou tout problème, ainsi que toute erreur ou piste d'amélioration dans ce document.

This is a not-so-short tutorial how to install GDL on an Unix/Linux/MacOS-X system, assuming you have few knowlegde on packages compilation and managment. If you follow the project information (INSTALL and README files coming with GDL) and using the blue boxes below, you should be able to obtain a basic succesful installation ! This document was devoted to the 0.8.11 version. Since that time, 0.8.12 and 0.9-pre appear. You should transpose to the new versions what is explained below. It is strongly recommanded to use the last version, with CVS patches !

Merci de lire !

Ce document contient des erreurs, principalement parce qu'il a été écrit en se basant sur une ancienne version de GDL, et que je ne pense pas toujours à prendre en compte tous les progrès faits (oui, FINDFILE est désormais disponible, mais RSI/ITT a remplacé cette fonction obsolète par FILE_SEARCH, elle aussi disponible dans GDL.)

Je reçois de plus en plus de demandes et de questions liées à ce document. C'est très bien, ce document est là pour ça, vous transmettre l'expérience limitée que j'ai accumulée sur cet excellent projet, et recevoir en retour vos commentaires, corrections, problèmes, et éventuelles questions.

Cependant, à plusieurs reprises, il était évident que le document n'avait pas été lu, ni même parcouru, ou que des connaissances de base manquaient. Pensez à vous adresser à vos experts locaux pour certaines questions et certaines taches ! Ceci n'est pas un cours d'IDL/GDL (Sven Geier a écrit une introduction (en PDF) pour les débutants), ni sur la compilation d'applications depuis le code source.

Si vous ne savez pas ce qu'est un fichier *.tar.gz ou *.tgz, si vous ne savez pas rajouter un RPM, ... si vous n'avez pas quelques bases en IDL/GDL, si x86_64 n'évoque vraiment rien pour vous, ce document n'est pas pour vous !

Si vous voulez réussir à installer GDL, merci de lire attentivement ce document. En particulier, pour les RPM, il faut absolument choisir ceux correspondant à votre distribution, sa version (fc4, mdk 10.1, ...) et l'architecture (x86 ou x86_64, ...). Si je dis qu'il faut au moins la version 4.0.1 pour GCC sous Mac OS X, ce n'est pas pour rien : la version 4.0.0 ne compilera pas.

Cependant, il peut traîner des typos, et certains systèmes ont des comportements différents que ceux principalement utilisés (Mandriva et Debian) pour préparer ce document et tester. En particulier, la plupart des autres systèmes Linux semblent exiger un chemin absolu et pas seulement un chemin relatif pour la relocation dans les configure.

Il est tout à fait possible de mener l'ensemble de la compilation sans avoir de privilèges super-utilisateur (root). Je recommande vivement cette approche, qui évite de risquer de casser le système ou d'y mettre le bazar. Par contre, pour l'installation de RPM (ou sous MAC OS X), il faut généralement être root. Sachez ce que vous faites ! Le bon coté, c'est que le packaging réduit les risques !

Il est vivement conseillé de passer en version CVS une fois la première compilation réussie. Et de surveiller la version CVS ! (en triant par "Âge" !)

N'espérez pas réussir sur un système bancal, que vous maîtrisez mal, ou une mauvaise politique de gestion des bibliothèques logicielles, des dépendances et des mises à jour aurait été appliquée.

GDL est (1) un logiciel libre (2) en développement. Il manque des fonctionnalités par rapport à IDL; il peut y avoir des bugs (je dois reconnaître que je peux compter sur les doigts d'une main les bugs avérés d'IDL).
Si vous êtes capables de programmer en C++ ou en syntaxe IDL la fonctionnalité qui vous manque dans GDL, vous pouvez la proposer aux développeurs. Sinon, n'hésitez pas à signaler gentiment que vous seriez contents qu'elle soit considérée prioritairement.
Si, dans GDL, vous trouvez un bug, un vrai, merci d'adresser un rapport de bug, aussi clair et complet et précis que possible (version de l'OS, plateforme (il n'y a pas eu beaucoup de tests sous x86_64) et version des bibliothèques) Il est possible de joindre un petit bout de code pour que d'autres testent de leur coté.

Nouveautés et correctifs

Remarques importantes

Qu'est que GDL ?

GDL est une alternative libre (licence GNU/GPL) à IDL. Essayez GDL ! (Je suis ce projet depuis la version 0.8.8, péniblement installée sur une Mandrake 9.0, Gcc 3.2, en faisant quelques tests et en signalant quelques bugs). Je fus assez surpris du bon comportement des versions 0.8.8 et 0.8.9, même si des bouts de code que j'emploie souvent dans IDL n'y étaient pas présents (comme FINDFILE, désormais présent, mais obsolète en IDL, remplacé par FILE_SEARCH, aussi disponible dans GDL ...)). Je suis enthousiaste depuis la version 0.8.11. Une petite discussion à propos de la sortie de cette version a d'ailleurs eu lieu sur le canal LinuxFr.org.

Objectif de ce mémo

Ce petit mémo n'a d'autre prétention que de donner des pistes pour vous incitez à installer ou compiler puis à tester GDL, voir même à faire co-exister IDL et GDL dans vos développements. Il se trouve, d'expérience, que même si la page officielle d'aide à l'installation est correctement faite, il est fréquent d'échouer sur des détails (Plplot et Python en particulier !). Cette page a donc pour but de fournir un moyen direct d'apprendre à compiler GDL et d'éviter certaines chausse-trappes (bugs avec NumArray, chemins, ...). Ensuite, il vous sera toujours possible de reprendre l'installation en rajoutant FFTw puis NumArray puis Python, ...

La description qui suit ne concerne que la version GDL 0.8.11 sous Linux. J'aborde surtout l'installation à partir de distributions Linux basées sur des packages RPM. Je suis ignorant en package DEB (packages sous Debian, avec Apt-get). Néanmoins, en ce qui concerne Plplot et GDL lui-même, je pars des *.tar.gz.

A priori, ceci doit être transposable sans trop de problème à Mac OS X et certains Unix, sous réserve d'installer ou de compiler un certain nombre de modules qui ne sont sans doute pas présent sur un Mac OS X ou un Unix de base.

GDL est interfacé avec Python. A la fois par désintérêt des fonctionnalités Python et de problèmes récurrents avec la localisation des bibliothèques Python lors des essais sur GDL 0.8.8, 0.8.9 et 0.8.10 et la version présente, je désactiverai Python.

Packages RPM pour Linux FC

On peut trouver des RPM de GDL packagés de frais pour Fedora Core 4 et FC 6 par Orion Poplawski (Merci !). L'avantage est que, si le package est bien fait, on est sur que ça va bien se passer ! L'inconvénient, c'est les dépendances.

Packages DEB pour Debian et Ubuntu

A ce jour, il n'existe pas de packages DEB pour GDL. Par contre, il semble qu'il y en ait pour Plplot, et toutes les autres bibliothèques indispensables sont disponibles (READLINE, GSL, ...).

Il m'a été rapporté des succès sans aucun problème sous Debian Sarge (x86) et Ubuntu (x86_64).

Packages pour Mac OS X 10.4

Un contributeur, Gaurav Khanna (Merci !), maintient un site dédié aux logiciels libres pour le calcul numérique et scientifique sous système d'exploitation Mac OS X (plateformes G4, G5 et Intel ...) (Fortran, MPI, OpenMP, PVM, Octave, GDL, Cactus, Globus, RNPL, GIMPS, GRAVSIM, FEYNMAN, Xmgr Grace, GNU Java, ...) et fournit des packages préparés des dernières versions, en particulier pour GDL.

Vous trouverez dans ce document une description plus extensive en français, pas à pas, de l'installation de ce package pré-compilé GDL 0.9-pre à partir de HPC sur un PowerPC G5 Mac OSX 10.4 (document qu'un collègue, Philippe Lemaire de l'IAS, m'a envoyé en juillet 2006).

[Quelques notes en attendant un vrai paragraphe sur la compilation sous Mac OS X] Pour compiler GDL sous Mac OS X, il *faut* GCC 4.0.1 sous 10.4, ce qui nécessite souvent une mise à jour. Il faut aussi recompiler plusieurs bibliothèques -dont READLINE- qui sont incomplètement présentes par défaut (header manquants). Quoique les descriptions ci-dessous soient OK en principe, il est recommandé aux néophytes impatients de se replier vers la version pré-compilée. Par contre, la compilation sous Mac OS X est possible et très formatrice !

Pré-requis

- un système récent sous GNU/Linux ou Unix ou Mac OS X
- (éventuellement) un système de packaging basé sur RPM (pour rajouter rapidement des packages manquants et adaptés au système)
- le compilateur GCC et ses bibliothèques
- les bibliothèques READLINE, Zlib, GSL, PLPLOT (et d'autres, mais qui sont en général présentes pour un système récent (moins de 5 ans d'âge !))

Il est à noter que l'installation qui suit ne nécessite en rien d'être root, sauf pour ajouter proprement les packages pré-existants qui pourraient manquer (READLINE, GCC, GSL, ...). Au pire, certains modules nécessaires tels GSL peuvent être compilés localement (./configure prefix=Mon/Rep/A/Moi), cf PLPLOT ci-dessous. La philosophie du document ici est justement de montrer comment tout recompiler depuis les fichiers source, sans avoir d'acces root, au détriment d'un peu de complexité.

Rappels

- la commande rpm -qa | 'toto' permet de vérifier si des packages contenant 'toto' sont déjà installés
- le caractère "\" indique que la commande continue à la ligne
- wget est, pour faire simple, un outil de ftp en mode commande.

Vérification du système et des bibliothèques présentes

Dans cette section, nous ne parlerons que des packages triviaux à installer, car fournis sous forme RPM dans les distributions utilisées.

Version du Kernel:

La compilation a été menée à bien pour une Mandriva 10.1 (Community) et une Mandriva 2006 officiel. Le présent document est lié à l'installation sur la Mandriva 10.1 (Community).

Version de Gcc:

Version de READLINE:

READLINE est une bibliothèque GNU très utile, en permettant de parcourir avec des commandes et des raccourcis la ligne courante (mêmes commandes dans (X)Emacs, sauter au début ou à la fin de la ligne, couper des bouts de ligne avant ou après le curseur, ...) et de rappeler les commandes précédentes.

Si READLINE n'est pas disponible en package pour votre distribution, ou si la version disponible est trop ancienne, ou, enfin, si le configure de GDL n'arrive pas à localiser cette bibliothèque, n'hésitez pas à l'installer à la main. Si on fait configure --help pour GDL, on constate qu'il existe une variable permettant de pointer directement vers la bibliothèque READLINE :
--with-readlinedir=DIR specify the GNU readline directory tree
On suivra la même procédure que pour PlPlot (configure puis make devrait suffire).

La version de Readline fournie par défaut dans Mac OS X (jusqu'au 10.4.8) est réputée inadéquate pour GDL, il est donc nécesaire de compiler la version GNU officielle en local.

Pour mémoire, à noter que GDL semble demander Ncurses aussi, mais à ce jour, personne n'a reporté de problème à son sujet.

De meme pour Zlib, en cas d'absence, il suffit de la compiler en local puis de faire pointer GDL dessus par: --with-zlibdir=DIR

Version de GSL:

A noter que la version minimale de GSL est la 1.4. Ceci est désormais testé dans le configure [gdl-0.9pre4].

GSL est une bibliothèque GNU de calcul numérique (produit de matrices, nombres complexes, ...). La version actuelle est 1.7. Mandriva en fournissant une plus ancienne, je l'utilise.

Néanmoins, pour des raisons de performance, il peut être raisonnable de recompiler, optimiser pour sa machine, cette GSL. Cependant, il peut être raisonnable de mener d'abord à bout la compilation complète de GDL, puis de reprendre et de compléter ces étapes d'optimisation marginales. Reportez aux paragraphes READLINE ou Plplot pour une compilation locale, ainsi qu'aux fichiers README et INSTALL généralement joints au (GSL est une grosse bibliothèque, longue à compiler et, surtout, à tester: il est chaudement recommander de faire tourner la suite de tests inclus: make check après la compilation (i.e. après le make)).

Compilation et Installation de Plplot

Plplot est une bibliothèque graphique permettant l'affichage de courbes, de surfaces et d'images 2D. Absente dans la distribution utilisée, ne disposant pas de RPM, il va falloir la compiler. Lorsque tout se passe bien, il faut compter de l'ordre de 1/4 heure pour compiler cette bibliothèque.

Cette compilation mérite quelques commentaires ! On récupère le code source par exemple chez OVH [1]. On décompresse et on extrait [2]. On va dans le répertoire ainsi créé [3]. Dans ce répertoire, on créé [4] un sous-répertoire de nom quelconque (ici, "COMPILATION"). On créé par [5] le "Makefile" par l'outil "configure" en précisant bien dans quel répertoire il faudra ensuite installer la bibliothèque compilée (il s'agit en fait d'une simple recopie des fichiers nécessaires). (Attention, la commande [5] ne marche pas sur toutes les distributions, il faut parfois donner le chemin absolu.) En fait, dans la commande [7], on recopie la bibliothèque compilée à l'étape [6] dans le sous-répertoire "COMPILATION". Cette manière de faire permet de ne pas avoir besoin d'être root et permet de travailler en local, dans l'arborescence sous son $HOME.

Pour information, il est possible de faire faire des tests automatiques lors de la compilation de cette bibliothèque, par $ make test. Ceci semble généralement poser quelques problèmes. Pour la Mandriva 10.1 utilisée, seulement 18 des 22 tests ont réussi.

Sur la version Mandriva 2006, la compilation pose problème à cause d'un conflit avec Python.

[Note du 16/07/2006] Depuis la version initiale de ce document, de nouvelles versions de PlPlot sont sorties. Je n'ai pas d'expérience positive avec elles sous Mandriva 2006 (x86 et x86_64).

[Notes du 20/09/2007] J'ai réussi à tester GDL avec divers versions de Plplot (dont plplot-5.6.1). Tout d'abord, niveau performance, ceci semble ne rien changer en rapidité d'affichage (tout à fait correct par rapport à IDL dans des cas comparables, cf testsuite/test_plot_benchmark.pro), sauf sous certaines plateformes (debian 3.1 et 4.0 en x86), ou on constate un eccart significatif entre IDL et GDL sur ces tests. Par ailleur, j'ai des problemes avec les versions récentes de Plplot (plus récentes que 5.5.3) avec GDL 0.9pre5 sous Mandriva 2006 et architecture x86_64 (pas de probleme en x86).

Compilation et Installation de GDL

Compilation:

Qu'il soit bien clair, les packages précédents sont nécessaires, la compilation ne pourra pas se faire sans tout cela. Nous souhaitions finaliser une première compilation avant de rentrer dans certains détails (Bibliothèque FFTw d'optimisation de calcul des FFT, Python, ImageMagick, ...) qui nécessitent parfois l'ajout d'autres libraires (Numarray pour Python, ...). Dans ce premier temps, nous désactivons tous les packages optionnels.

Lorsque tout se passe bien, il faut compter de l'ordre d'un gros 1/4 heure pour compiler cette bibliothèque.

[1]$ wget http://ovh.dl.sourceforge.net/sourceforge/gnudatalanguage/gdl-0.8.11.tar.gz
[2]$ tar -zxf gdl-0.8.11.tar.gz
[3]$ cd gdl-0.8.11
[4]$ ./configure --with-Magick=no --with-netcdf=no --with-hdf=no \
--with-hdf5=no --with-python=no \
--with-plplot=/CheminVersPlplot/plplot-5.5.3/COMPILATION/
[5]$ make
[6]$ ./src/gdl

Les 3 premières lignes sont "comme d'habitude". Par contre, les options sont nombreuses pour la future compilation de GDL [4]. Nous ne souhaitons pas compiler avec certaines bibliothèques, en particulier avec Python (langage de commande), HDF, HDF5 et NetCDF (formats de données) et la bibliothèque ImageMagick (format d'images de sortie). Attention, il faut bien faire attention au chemin pour la bibliothèque Plplot. La compilation est faite par [5]. L'exécutable est rangé dans le sous répertoire src/. On peut le lancer directement par [6].

Le problème fréquemment rencontré est l'absence de chemin d'accès pour la bibliothèque Plplot. Si un message "missing libplplot.so", pensez à rajouter le chemin "/CheminVersPlplot/plplot-5.5.3/COMPILATION/" dans $PATH.

Installation:

Une fois la compilation réussie, l'installation se fait par un simple : make install. Selon le cas, en particulier si vous n'avez pas changer les options par défaut, il faudra sans doute avoir les privilèges root. Il est possible de jouer sur les chemins (au niveau du configure, cf configure --help, lignes "prefixe") afin de ne plus avoir besoin d'être root.

En fait, vous avez plusieurs choix.
Si votre machine est un ordinateur personnel, il n'est pas indispensable de faire copier par make install les fichiers nécessaires à GDL dans une arborescence système. Vous pouvez d'ores et déjà jouer avec GDL qui est dans le sous-répertoire src/, et les procédures externes sous src/pro/. De plus, si vous comptez tester et comparer plusieurs versions de GDL (il est recommander de tester les versions CVS !), il vaut mieux ne pas déployer ces versions sur une même arbo système.
Si votre machine est un ordinateur avec plusieurs utilisateurs intéressés par GDL, il peut être bon de poser une ou plusieurs versions en parallèle. Il faudra veiller à tenir informer les utilisateurs des évolutions éventuelles des chemins, de l'ajout des versions CVS, et des bibliothèques, sous peine sinon d'avoir plusieurs versions des mêmes bibliothèques (même si ceci n'est plus vraiment gênant aujourd'hui avec la taille des disques durs !).

Succès et échecs de compilation et d'installation

On parle ici que de la version 0.8.11 et d'une compilation (C) ou d'une installation (I). L'installation par des RPM ou autres systèmes de packagings n'est pas détaillée.

Compilations et Installations réussies

L'installation (I) directe par package est possible pour certaines machines: FC, Debian, Mac OS X.

La compilation (C) a été réussie à ce jour seulement sur des machines Linux 32 et 64 bits (x86_32 et x86_64) ... Il faut bien voir qu'il est trivial de compiler la version CVS (pre-0.8.12) des lors que l'on sait compiler la version 0.8.11.

Un gros travail a été fait sur les versions 0.9pre pour faciliter la compilation from scratch, en particulier pour x86_64 et Mac OS X, merci de reporter vos éventuels soucis pour que nous puissions les prendre en compte.

Machines 32 bits
- (I) Mac OS X
- (C) [depuis 0.9pre4] Mac OS X (10.4.7 (from scratch) et 10.4.9 (problème de lien vers lib. X11))
- (C) [depuis 0.8.11] Mandriva 2006 sur portable 32b
- (C) [depuis 0.8.11] Mandriva 10.1 sur portable 32b
- (C) [depuis 0.8.11] Debian Sarge (3.1) sur fixe et portable 32b
- (C) [depuis 0.8.11] Fedora Core 1 sur fixe 32b (Attention, il faut éditer du code, cf bug connu (nous confirmons que ceci corrige le problème à la compilation de GDL))
- (C) [depuis 0.9pre4] Scientific Linux SL release 4.3 (Beryllium) (Attention, en cas d'usage de librairies locales --compilées sur un compte non-root, il peut falloir modifier le LD_LIBRARY_PATH. Exemple:
  export LD_LIBRARY_PATH=/home/master/gsl-1.9/COMPILATION/lib
  pour pouvoir ensuite compiler avec cette version locale de la GSL. Ce genre de subtilité n'a pas été reportée à ce jour sur d'autres plateformes.
Machines 64 bits
- (I) Ubuntu sur Opteron (sans aucun problème)
- (C) Debian Etch (4.0) sur x86_64
- (C) Mandriva sur Opteron (Linux 2.6.12-12mdksmp #1 SMP Fri Sep 9 17:20:34 CEST 2005 x86_64 AMD Opteron (tm) Processor 846 unknown GNU/Linux)
  Ceci a été corrigé dans le CVS (pre-0.8.12). Le problème semble lié à X11 et la coexistence de lib/ et lib64/ Il faut éditer à la main le Makefile dans src/ pour remplacer /usr/X11R6/lib par /usr/X11R6/lib64 (en fin de compilation). On reprend le make local puis le make global.
- (C) Fedora Core sur Opteron
  1/ il faut faire la même chose que pour le FC1 sous 32b (bug corrigé dans le CVS)
  2/ il faut faire la même chose que pour la Mandriva sous Opteron (en fin de compilation)

Echecs

Attention, tout d'abord je tiens à préciser que les causes de l'échec sont le plus souvent externes à GDL. Par exemple, la bibliothèque PLPLOT est délicate à installer.

Tru64 OSF1 V5.1 2650 alpha
le problème semble lié au compilateur CC
Mandrake 9.0
Le problème semble lié à certains headers de GDL et du GCC
Mandriva 2006 sur x86_64
Il semble y avoir un conflit entre des versions récentes de Plplot et GDL 0.9pre5 sur archi x86_64. La compilation se passe bien, ca plante à l'exécution.

Liste des Procédures et Functions

Procédures et fonctions intrinsèques

En attendant une documentation plus sympathique, la liste de toutes les procédures et fonctions intrinsèques d'ores et déjà disponibles est concaténé dans un 1er fichier ASCII.

Procédures et fonctions contributives

IDL vient avec environ 300 procédures et fonctions contributives officielles à code ouvert (elles sont distribuées avec le CD d'IDL, il ne s'agit pas de les rajouter a posteriori comme IDL-ASTRON à la NASA, CraigMPfit, TexToIDL, ...), Il s'agit de ces pro/func rangées dans l'arborescence lib/. Quoique le code en soit ouvert, le ré-usage dans GDL pourrait poser des problèmes légaux, même si vous avez une licence officielle d'IDL. On pourrait imaginer une situation ou on monte par NFS pour une machine sans IDL mais avec GDL le disque d'une machine avec une licence d'IDL, ce disque contenant ces bibliothèques. Ou bien une machine avec un nombre de licences limitées d'IDL, et GDL à coté ... (à noter la grande similitude avec les drivers propriétaires de certaines cartes Wifi, utilisés sous forme binaire par linux.)

Afin de mettre à disposition de tous une version GDL vraiment complète, et corrolairement afin de déminer d'éventuels problèmes légaux, qui arriveront sans doute dès que GDL sera reconnu par RSinc comme la menace sérieuse qu'il devient, un certain nombre de ces procédures sont en cours de ré-écriture. (Vous pouvez contribuer, une liste informelle des priorités a même été établie !) En attendant une documentation plus sympathique, la liste des clones des procédures et fonctions contributives d'ores et déjà disponibles est concaténé dans un 2ème fichier ASCII. On remarquera que certaines profitent déjà de cette ouverture du code en accueillant des extensions ! (tout en restant compatibles)

Procédures et fonctions externes

Il est d'ores et déjà possible de réemployer, en toute légalité, un certain nombre de procédures et fonctions diffusées dans des packages non lies à IDL, comme, déjà cités: Astron, TexToIDL, ... C'est d'ailleurs par ce biais que j'ai pu tester la relecture d'images FITS !

Pour les néophytes, le plus délicat est sans doute d'activer correctement les chemins, par paire au choix: GDL_PATH et GDL_STARTUP ou IDL_PATH et IDL_STARTUP.
GDL_PATH sert à indiquer les chemins que GDL doit prendre en compte pour rechercher les modules, et dans quel ordre
GDL_STARTUP indique le nom du fichier d'initialisation de la session.

La bibliothèque CMSVLIB

Cette bibliothèque ( explications téléchargement direct) doit etre ajoutée dans le chemin de GDL si on veut avoir acces à SAVE et RESTORE. A noter que, par rapport à IDL, pour le moment, SAVE/RESTORE de GDL ne permet pas de : (1) sauver toutes les données courantes (SAVE,/all est inactif) et (2) de sauver du code.

La bibliothèque MPFIT

La bibliothèque MPFIT ( explications, tutorial, téléchargement direct) est très intéressante par rapport à d'autres bibliothèques équivalentes ou procédures internes à IDL/GDL (genre CURVEFIT) par la facilité de basculer d'un mode sans contrainte à un mode avec contraite, voire meme en fixant un des paramètres.

Elle fonctionne désormais sans modification avec la version CVS de GDL 0.9pre4. J'ai écrit un petit programme de vérification.

Post-installation : Usage du CVS

Pour mémoire, CVS est un système de gestion des versions (il en existe d'autres, comme Subversion ou Git (orienté développement du noyau linux)).

La version en cours de développement de GDL est stockée sous CVS afin de permettre à plusieurs personnes de travailler en parallèle sur le projet. Tant qu'il n'y a pas de conflit sur les modifications, c'est transparent pour les développeurs, qui téléchargent du serveur (ici la forge SourceForge) l'état actuel (checkout) puis envoient leurs modifications (commit).

Réinstallation complète

On suppose qu'une version complète (par exemple la 0.8.11) est déjà installée. On va profiter des bibliothèques de la version GDL déjà présente pour installer rapidement la version en cours de développement, sans écraser la version GDL précédemment installée (réinstallation à coté).

Dans notre cas, utilisateur passif de la version pré-0.8.12, il suffit de faire un téléchargement complet à coté de la version 0.8.11.

[1] $ cvs -v
[2] $ mkdir MonNouveauDir_pour_GDL
[3] $ cd MonNouveauDir_pour_GDL
[4] $ cvs -d:pserver:anonymous@gnudatalanguage.cvs.sourceforge.net:/cvsroot/gnudatalanguage login
[5] $cvs -z3 -d:pserver:anonymous@gnudatalanguage.cvs.sourceforge.net:/cvsroot/gnudatalanguage checkout gdl
[6-7-8] (configure & make & make install)

(Naviguez dans le CVS !) Vous pouvez ensuite, par cette interface WEB, connaître les dernières nouveautés et modifications par ordre chronologique.

Quelques explications: [1] est juste pour vérifier vite fait si le programme cvs est bien présent sur la machine. Pour ne pas écraser une autre version de GDL, on crée [2] un nouveau répertoire (MonNouveauDir_pour_GDL) et on s'y rend [3]. On se connecte [4] sous forme anonyme au CVS de SourceForge pour l'arborescence GnuDataLanguage. La commande [5] permet de télécharger tous les fichiers du projet GDL en respectant l'arborescence, et en créant une racine gdl/.

En supposant qu'une ancienne version de GDL est présente, pour compiler cette nouvelle version (ici étapes non détaillées notées [6-7-8]), il suffit d'aller dans la nouvelle racine gdl/ puis de reprendre l'étape de compilation seulement, puisque les autres modules et bibliothèques sont déjà présents. Bien évidemment, il faut sauter les étapes [1] à [3] (du paragraphe compilation !) puisqu'on a déjà préparé le package par le cvs checkout.

Usage incrémental du CVS

Supposons qu'une précédente version CVS a déjà été rapatriée et compilée avec succès, par exemple dans un répertoire /home/coulais/GDL/gdl-0.8.12cvs/. On va se rendre dans ce répertoire, puis, après identification, on va demander au serveur de nous fournir seulement les fichiers mis à jour (sur le serveur) par rapport à la version locale (notre ordinateur).

A noter que, comme dans tout projet géré par un make, comme tout le reste ne change pas (a priori), il suffit de refaire le make sans le configure (gain de temps !), et le make ne recompilera que ce qui est réellement dépendant des nouveaux fichiers (second gain de temps !) Bien évidemment ceci n'a de sens que si vous n'avez pas effacé les fichiers intermédiaires de compilation (les *.o) !

[1] $ cd /home/coulais/GDL/gdl-0.8.12cvs/
[2] $ cvs -d:pserver:anonymous@gnudatalanguage.cvs.sourceforge.net:/cvsroot/gnudatalanguage login
[3] $ cvs -z3 -d:pserver:anonymous@gnudatalanguage.cvs.sourceforge.net:/cvsroot/gnudatalanguage upgrade
[4] $ make
[5] $ make install

Si vous avez déjà une version CVS, le temps pour faire ceci est de quelques dizaines de secondes pour le rapatriement des nouveautés, et de quelques secondes pour la compilation ... Le gain par rapport à une compilation complète est alors évident ! Et vous disposez des dernières mises à jour et correction de bugs !

Test et bogues

Tests

Voici quelques programmes de test fonctionnant avec GDL 0.8.11 ou la version CVS:

Bugs corrigés

Bugs non corrigés à ce jour, ou fonctionnalités manquantes

Merci de me signaler vos problèmes, si possible avec un bout de code.

Merci cependant de ne pas confondre un problème réel (donc intéressant) avec :

le résultat d'une compilation incomplète (par ex.: READ_PNG/JPEG et WRITE_PNG/JPEG ne fonctionneront pas si la compilation a été faite sans ImageMagick ...)
une configuration incomplète (par ex.: le GDL_PATH doit contenir le chemin vers les *.pro fourni avec GDL !)

Temps de calcul: IDL vs GDL

Opérations élémentaires et FFT

Nous avons vu que les syntaxes IDL et GDL, à quelques micro-détails près, sont identiques. Quand est-il du temps de calcul ? A l'aide de ce petit test des opérations arithmétiques élémentaires qui tourne sur IDL et GDL, on se rend compte que, excepté pour l'élévation au carré, les temps sont, à 10/20% près, comparables. Après échange avec le développeur principal, le surcoût lors du calcul des puissances (test des puissances (entières et fractionnaires) devrait être corrigé dans la version 0.8.12.

Sur TOTAL, les temps avec GDL sont doubles des temps IDL *en simple précision*. En fait, les calculs GDL sont toujours fait en double dans ce cas, d'ou cette pénalité ! Dans le cas du calcul de la Constante d'Euler-Mascheroni, par la grâce de la double précision *cachée* par GDL, on obtient un résultat semblable obtenu par sommation de Kahan, tandis que la version simple précision par IDL diverge !

Comme déjà mentionné, les FFT internes à GDL sont 2 à 4 fois plus longues que celles dans IDL. En étant conscient, le team GDL a décidé, vers la version 0.8.9, de permettre d'utiliser à la place la référence: FTTw, que je n'ai pas testé à ce jour.

Depuis début Mars 2007, j'ai appris à compiler avec FFFw3, et les FFT sont, à partir de 2L^13 (soit 8192) points, en 2^N (seuls test faits à ce jour), sous plateform x86, plus rapides que la FFT intrinsèque à IDL (testée sur la même machine). Voir la nouvelle section sur FFTw.

Comparaison avec d'autres langages

Je profite de ce passage pour faire une brève digression sur les temps de calcul entre IDL (et GDL), Fortran et C/C++ (en Python). Des tests faits, en respectant les règles de syntaxe IDL/GDL (éviter les boucles explicites, travailler sur les tableaux, utiliser les bons opérateurs, ...) les temps de calcul bruts sont comparables à ceux obtenus par Fortran ou C/C++. Cependant, il faut bien voir que ceci n'a de sens que si les calculs sont "compatibles" avec la syntaxe IDL/GDL. Si la nature du problème nécessite des boucles longues (For), imbriquées, avec des branchements (If), il faudra sans doute se tourner vers des langages compilés.

Il y a un petit supplément systématique à utiliser IDL/GLD par rapport à un langage compilé. Sur les machines actuelles, c'est infime. Par contre, le temps de développement et le temps passé à traquer les bugs sont clairement largement inférieurs en IDL/GDL. Et on garde la main sur ses données (Help) !

La limite pratique est désormais plutôt la taille mémoire allouable. En IDL/GDL, elle est dynamiquement allouée, comme en C/C++. Et ses limites sont les mêmes que C/C++. Ce n'est donc pas un point bloquant, dès le moment ou on connaît les ordres de grandeur !

La bibliothèque ImageMagick

Une fois obtenue la compilation de base, il est vivement recommandé de considérer l'ajout de la bibliothèque ImageMagick, car sa prise en compte rendra opérationnelle des procédures disponibles comme READ_PNG, READ_JPEG, WRITE_PNG et WRITE_JPEG. On n'a pas toujours à disposition le bon .RPM ou .DEB. Et sa compilation est un peu délicate sur certains systèmes, d'autant qu'il faut, pour avoir le PNG et le JPEG d'actif, bien avoir les bibliothèques correspondantes et les *.h dans /usr/include ...

Jusqu'à présent, tous les modules présentés ici se compilaient et se posaient sans problème depuis un compte utilisateur, sans avoir d'accès root. Pour continuer dans cette voie avec ImageMagick, il y a une petite subtilité liée à Perl.

[1] $ cf http://www.imagemagick.org/script/download.php
[2] $ tar -zxf ImageMagick.tar.gz
[3] $ cd ImageMagick-6.3.3
[4a] $ mkdir MaCompil
[4b] $ cd MaCompil
[4c] $ mkdir Perl
[4d] $ cd ..
[5] $ ./configure --prefix=$PWD/MaCompil --with-perl-options=PREFIX=$PWD/MaCompil/Perl
[6] $ make
[7] $ make install

Comme toujours, il vous faudra adapter en fonction de la version de la bibliothèque que vous recupèrerez. La seule subtilité est dans la ligne [5], préparée par les opérations [4*], qui consiste à faire installer les résultats liés à Perl non pas dans l'arbo système mais en local. En sortie du configure de ImageMagick, vérifiez bien si les option PNG et JPEG sont "yes", sinon, a priori, cela veut dire qu'il vous manque les entêtes (bibliothèques de développement) de PNG et JPEG. Ensuite, une fois la compilation (make) et le déploiement (make install) effectifs, il suffit de revenir au configure de GDL et de préciser le chemin vers ImageMagick (--with-Magick=Le/Chemin/Vers/ImageMagick-6.3.3/MaCompil)

[Notes du 20/09/2007] J'ai recu un message de F. Thais qui donne des précisions sur certaines options de compilation de LibTiff et d'Image Magick qui permettent d'activer la compression dans WRITE_TIFF de GDL (merci pour ces utiles précisions, bien cachées).

GDL et FFTw

Il est recommande d'utiliser la bibliothèque FFTw3 pour obtenir les meilleures performances possibles pour le calcul des FFT. L'installation se fait sans trop de problème, mais il y a une subtilité (il faut compiler deux fois, une fois en simple et l'autre en double ! [libfftw3.a et libfftw3f.a]) Le test sur les 2 bibliothèques est désormais (GDL 0.9pre4 CVS) plus explicite.

[1] $ wget http://www.fftw.org/fftw-3.1.2.tar.gz [vérifiez s'il n'y a pas une version plus récente !]
[2] $ tar -zxf fftw-3.1.2.tar.gz
[3] $ cd fftw-3.1.2
[4] $ mkdir MaCompil
La compilation normale
[5] $ ./configure --prefix=$PWD/MaCompil
[6] $ make
[7] $ make install
La compilation single
[8] $ ./configure --prefix=$PWD/MaCompil --enable-single
[9] $ make
[10] $ make install

Désormais, un "ls fftw-3.1.2/COMPILATION/lib" donnera, entre autre, libfftw3.a et libfftw3f.a. Il faut ensuite reprendre le configure de GDL en précisant le chemin de la bibliothèque FFTw3, par --with-fftw=Le/Chemin/Vers/fftw-3.1.2/MaCompil. Il faut vérifier, vers la fin de la compilation du configure, que l'appel par défaut à la FFT de GSL a été remplacé par celui à FFTw.

Dès que le nombre de points dépassent 2L^13 (8192), les test montrent que la FFTw dans GDL est plus rapide que la FFT dans IDL sur machine x86_32.

J'ai écrit un petit code (test_fftw.pro) qui présente surtout l'intérêt de sauver les calculs et de permettre d'inter-comparer graphiquement les calculs entre différentes machines. (Et je compte poser dès que possible des résultats ! Il vous faudra installer GDL avec la bibliothèque CMSSAVE pour les Save/Restore).

GDL et la cartographie

Une procédures de test (test_maps.pro) est désormais intégrée dans l'arborescence testsuite/ du CVS.

Attention : il semble y avoir un bug avec le mot-clef limit=[lat_min,lon_min,lat_max,lon_max] dans la version x86_64. (InterpreterLoop: Exception: St9bad_alloc)

GDL, Debian et Ubuntu

Je ne connais pas bien le système Debian. Cependant, on m'a rapporté l'installation avec succès sur Debian Sarge (3.1) et Etch (4.0) sur des machines x86_32 et x86_64. Et j'ai participé à la finalisation d'installations (Sarge sur x86_32 et Etch sur x86_64).

Pour lister les packages sous Debian, on peut faire:
COLUMNS=74 dpkg -l | grep Partie_du_NomDuPackage
l'avantage ici est qu'on n'a pas besoin de connaitre le nom exact du package.

Pour lister les packages disponibles, on peut faire:
apt-cache search NomDuPackage
ici, il faut connaitre le nom exact du package ...

Sous Debian, presque tout est déjà disponible sous forme de package: Readline, Zlib, ImageMagick, Plplot, ..., ce qui est un gain de temps considérable. A part GDL, les 2 seuls packages qui semblent manquer seraient FFTw et Libproj4 ! Donc, sous Debian, sollicitez donc votre administrateur système pour qu'il vous installe le plus possible des packages liés à GDL ! Je donne ici une liste indicative des packages présents pour une version Sarge (3.1) ou GDL a été compilé avec succès. Clairement, certains de ces packages ne sont pas nécessaires à GDL ! Mais ce n'est pas toujours très clair ...

ii imagemagick 6.0.6.2-2.9 Image manipulation programs
ii libmagick++6 6.0.6.2-2.9 The object-oriented C++ API to the ImageMagi
ii libmagick++6-d 6.0.6.2-2.9 The object-oriented C++ API to the ImageMagi
ii libmagick6 6.0.6.2-2.9 Image manipulation library
ii libmagick6-dev 6.0.6.2-2.9 Image manipulation library -- development
ii perlmagick 6.0.6.2-2.9 A perl interface to the libMagick graphics r
ii zlib1g 1.2.2-4.sarge. compression library - runtime
ii zlib1g-dev 1.2.2-4.sarge. compression library - development
ii gsl-bin 1.6-2 GNU Scientific Library (GSL) -- binary packa
ii gsl-ref-psdoc 1.6-1 GNU Scientific Library (GSL) Reference Manua
ii libgsl0 1.6-2 GNU Scientific Library (GSL) -- library pack
ii libgsl0-dev 1.6-2 GNU Scientific Library (GSL) -- development
ii libreadline4 4.3-11 GNU readline and history libraries, run-time
ii libreadline5 5.0-10 GNU readline and history libraries, run-time
ii tclreadline 1.2.0-6 GNU Readline Extension for Tcl/Tk
ii libplplot9 5.3.1-4 Scientific plotting library

Ubuntu est une distribution issue de Debian qui a actuellement le vent en poupe. On pourra lire un fil de discussion pour les utilisateurs d'Ubuntu désirant installer GDL. Une partie des conseils est transposable à Debian.

Bien évidemment, tout ceci devrait se transposer sans problème pour les autres distributions basées sur Debian et Ubuntu (Kubuntu (en, fr), Xubuntu, EduBuntu, ...)

GDL et Gentoo

Tout d'abord, je regrette de ne pas avoir de machine sous Gentoo, plus un manque de temps qu'un manque de curiosité !

Lors d'un TP ici, un étudiant a fait un simple emerge et voilà qu'il avait la dernière version sur son portable ...

Compiler GDL sur MAC OS X

Ne pas le compiler mais l'installer via Fink !

Je recommande vivement cette approche, mais pensez ensuite à vérifier si les *.pro de src/pro/ sont bien dispo pour vous.

Comme noté ci-haut, un contributeur, Gaurav Khanna, maintient un site dédié aux logiciels libres pour le calcul numérique et scientifique sous système d'exploitation Mac OS X (plateformes G4, G5 et Intel ...). Cependant, ses binaires GDL commencent à dater.

Préambule à la compilation

Nouveauté au 23 Mars 2007. Je remercie en particulier Grégory Marchal pour ses retours sur ce sujet.

Il y a une demande assez significative concernant GDL sur Mac OS X. N'ayant pas accès à un Mac "bien configuré" ni les compétences pour faire certaines opérations (mise à jour de GCC), je n'ai pas pu finir moi-meme la compilation sur Mac OS X.

Il y a plusieurs eccueils sur Mac OS X. Le premier est que certains bibliothèques standart sous Linux sont ici installées dans des arborescences exotiques. Le second est que certains headers (*.h) de certaines bibliothèques sont parfois absents, ou bien mal rangés, ou bien que des liens importants sont faux ou cassés. Ceci est assez connu dans le monde des développeurs pour Mac OS X. Le problème est que cela est plutot décourageant pour le néophyte !

Plateforme Mac OS X à processeur Intel

Ce nouveau paragraphe sera surtout consacré à la compilation de GDL sous plateforme Mac OS X à processeur Intel. Cependant, il devrait etre valable pour les anciens MAC si le systeme est à jour (OS X 10.4.9).

En respectant scrupuleusement les étapes de compilation, il sera possible sans difficultés de compiler READLINE, GSL ... Ensuite, on constate que la derniere version de Plplot (5.6.2) ne compile pas. Par contre la version 5.5.3 convient. On trouvera un exemple ici (Merci à Grégory !).

Une fois compilées toutes ces bibliothèques (comme toujours, je recommande une compilation en local), on attaque d'abord la compilation du TGZ de GDL-0.9pre4, qui devrait se faire sans soucis.

Enfin, il est vivement recommandé de faire la mise à jour CVS. Mais, à l'heure ou j'écris ces lignes (23 Mars 2007), la version CVS ne compile pas à cause du programme src/print.cpp. Il faut commenter une dizaine de lignes pour passer outre. Ceci sera sans doute rapidement corrigé dans le CVS, mais rien n'est jamais sur dans le monde des logiciels libres !

Lors de la compilation, on peut avoir des messages d'erreur liés à des entetes X11. Dans ce cas, il faudra modifier à la main des liens dans le système ... Ce genre de vrai-faux bugs est typique d'un système exotique !

Sous processeur Intel, avec Mac OS X 10.4.7 "propre", il m'a été reporté une compilation sans aucun problème de la version GDL 0.9pre4 avec la dernière version Plplot (5.6.2).

Conclusion

Tout n'est pas encore clair ou évident avec la compilation de GDL. Par exemple, de nombreux problèmes ont été rencontrés en ce qui concerne la relation avec Python, NetCDF et d'autres packages. La localisation de certaines bibliothèques, réellement présentes, semble parfois poser problème (ceci était déjà le cas avec GDL 0.8.8 et READLINE sur une vieille Mandrake 9.0). En partant de rien, en comptant les allers et retour, il faut compter deux bonnes heures pour parvenir à une compilation complète a minima. Il est vivement recommander de passer aussitôt à la version CVS et de surveiller les progrès de GDL.

Dans certains cas particuliers (Fedora Core, Mac OS X), des versions packagées sont disponibles, ce qui fait gagner un temps considérable, mais prive des mises à jour par CVS.

Certaines plateformes sont bien plus avantageuses que d'autres, par exemple Debian ou même Plplot est déjà packagé. Sous Mandriva, il faudra passer du temps à compiler Plplot et ImageMagick mais il n'y a pas trop de surprise. Des efforts sont en cours pour rendre plus explicites les messages d'avertissement et d'erreur lors du configure de GDL.

Sans jugement sur le système Mac OS X, cette plateforme semble très désavantageuse pour compiler from scratch GDL avec les autres bibliothèques nécessaires (dont Readline), pour diverses raisons. Certaines bibliothèques (par ex. Readline), quoique présentes en apparence sous Mac OS X posent problème pour GDL et exigent d'etre recompilées. Certains fichiers entêtes (*.h) sont absents ou posés dans des arborescences exotiques. Enfin, la plateforme matériel Intel n'est pas encore bien consolidée pour certaines bibliothèques (par ex. Plplot). Heureusement, une version packagée dans Fink est désormais disponible (septembre 2007).

Une fois la compilation ou l'installation terminée, on se retrouve avec un système tout à fait correct, si on n'a pas besoin d'un code manquant, ou si on ne sait pas comment le contourner. Avec un collègue, nous avons ainsi réussi à lire avec les procédures liées à READFITS une image HST encodée au format FITS et à l'afficher. Un certain nombre de procédures très utiles (RANDOMU et RANDOMN) sont désormais disponibles. Le temps d'affichage pour des tracés 1D d'un grand nombre de points est tout à fait correct (genre de test rédhibitoire pour certaines bibliothèques graphiques vieillissantes, comme ce qui était utilisé pour Aips++ (tcl/tk)).

Obsolete, merci de suivre ce lien

Compilation ou installation de GDL sous GNU/Linux ou Mac OS X

Résumé (summary)