Documentation PostgreSQL 8.2.23 The PostgreSQL Global Development Group ------------------------------------------------------------------------------- Chapitre 1. Procédure d'installation de PostgreSQLâ„¢ 1.1._Version_courte 1.2._Prérequis 1.3._Si_vous_effectuez_une_mise_Ã__jour 1.4._Procédure_d'installation 1.5._Initialisation_post-installation 1.6._Démarrer 1.7._Et_maintenant_? 1.8._Plateformes_supportées Ce document décrit l'installation de PostgreSQLâ„¢ à partir du code source (si vous installez une distribution préparée, tels qu'un paquetage RPM ou Debian, vous pouvez ignorer ce document et lire à la place les instructions du mainteneur du paquetage). 1.1. Version courte ./configure gmake su gmake install adduser postgres mkdir /usr/local/pgsql/data chown postgres /usr/local/pgsql/data su - postgres /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data >logfile 2>&1 & /usr/local/pgsql/bin/createdb test /usr/local/pgsql/bin/psql test Le reste du document est la version longue. 1.2. Prérequis En général, les plateformes style unix modernes doivent être capables d'exécuter PostgreSQLâ„¢. Les plateformes sur lesquelles des tests ont été effectuées sont listées dans la Section_1.8,_«_Plateformes_supportées_» ci-après. Dans le répertoire doc de la distribution, il y a plusieurs FAQ spécifiques à des plateformes particulières que vous pouvez consulter si vous avez des problèmes. Les logiciels suivants sont nécessaires pour compiler PostgreSQLâ„¢ : * GNU make est nécessaire ; les autres programmes make ne devraient pas fonctionner. GNU make est souvent installé sous le nom gmake ; ce document fera toujours référence à lui sous ce nom (sur certains système, GNU make est l'outil par défaut et est nommé make). Pour savoir quelle version vous utilisez, saisissez gmake --version Il est recommandé d'avoir une version postérieure à la version 3.76.1. * Il est nécessaire d'avoir un compilateur C ISO/ANSI. Une version récente de GCCâ„¢ est recommandée mais PostgreSQLâ„¢ est connu pour être compilable avec de nombreux compilateurs de divers vendeurs. * tar est requis pour déballer la distribution des sources avec soit gzip soit bzip2. * La bibliothèque GNU Readlineâ„¢ est utilisée par défaut (pour une édition facile des lignes et une recherche de l'historique des commandes). Si vous ne voulez pas l'utiliser, il vous faut spécifier --without-readline au moment d'exécuter la commande configure. Une alternative possible est l'utilisation de la bibliothèqe libedit sous license BSD, développée au début sur NetBSDâ„¢. La bibliothèque libedit est compatible GNU Readlineâ„¢ et est utilisée si cette dernière n'est pas trouvée ou si --with-libedit- preferred est utilisé sur la ligne de commande de configure. Si vous utilisez une distribution Linux basée sur des paquetages, faites attention au fait que vous aurez besoin à la fois des paquetages readline et readline- devel s'ils sont séparés dans votre distribution. * La bibliothèque de compression zlibâ„¢ sera utilisée par défaut. Si vous ne voulez pas l'utiliser, alors vous devez spécifier l'option --without-zlib à configure. Utiliser cette option désactive le support des archives compressées dans pg_dump et pg_restore. * Des logiciels supplémentaires sont nécessaires pour construire PostgreSQLâ„¢ sur Windowsâ„¢. Vous pouvez construire PostgreSQLâ„¢ pour les versions NTâ„¢ de Windowsâ„¢ (comme Windows XP et 2003) en utilisant MinGWâ„¢ ; voir doc/FAQ_MINGW pour les détails. Vous pouvez aussi construire PostgreSQLâ„¢ en utilisant Cygwinâ„¢ ; voir doc/FAQ_CYGWIN. Une construction basée sur Cygwinâ„¢ fonctionnera sur les anciennes versions de Windowsâ„¢ mais, si vous avez le choix, nous vous recommandons l'approche de MinGWâ„¢. Bien qu'il soit le seul ensemble d'outils recommandé pour une construction complète, il est possible de construire seulement la bibliothèque cliente C (libpq) et le terminal interactif (psql) en utilisant d'autres environnements de développement sous Windowsâ„¢. Pour des détails, voir le le chapitre «Installation sur Windowsâ„¢ du seul client » de la documentation. Les paquetages suivants sont optionnels. Ils ne sont pas obligatoires pour une compilation par défaut mais le sont lorsque certaines options sont utilisées ainsi que c'est expliqué par la suite. * Pour installer le langage de procédures PL/Perl, vous devez avoir une installation de Perlâ„¢ complète, comprenant la bibliothèque libperl et les fichiers d'en-tête. Comme PL/Perl est une bibliothèque partagée, la bibliothèque libperl doit aussi être partagée sur la plupart des plateformes. Ce qui n'est le cas que dans les versions récentes de Perlâ„¢ et, dans tous les cas, c'est le choix de ceux qui installent Perl. Si vous avez l'intention d'avoir plus qu'une utilisation occasionnelle de PL/Perl, vous devez vous assurer que l'installation de Perlâ„¢ a été faite avec l'option usemultiplicity activée (perl -V vous indiquera si c'est le cas). Si vous n'avez pas de bibliothèque partagée alors qu'il vous en faut une, un message tel que celui-ci apparaîtra durant la compilation pour vous en avertir : *** Cannot build PL/Perl because libperl is not a shared library. *** You might have to rebuild your Perl installation. Refer to *** the documentation for details. (Si vous ne suivez pas la sortie écran, vous pourrez constater que la bibliothèque plperl.so de PL/Perl, ou similaire, n'est pas installée.) Si c'est le cas, il vous faudra recompiler et ré-installer Perlâ„¢ manuellement pour être capable de compiler PL/Perl. Lors de la phase de configuration de Perlâ„¢, demandez que les bibliothèques soient partagées. * Pour compiler le langage de procédures PL/Python, il faut que Pythonâ„¢ soit installé avec les fichiers d'en-tête et le module distutils. Le module distutils est inclus par défaut avec Pythonâ„¢ 1.6 et les versions suivantes ; les utilisateurs des versions précédentes de Pythonâ„¢ auront besoin de l'installer. Puisque PL/Python devra être une bibliothèque partagée, la bibliothèque libpython doit l'être aussi sur la plupart des plateformes. Ce n'est pas le cas pour une installation par défaut de Python. Si, après la compilation et l'installation, vous avez un fichier nommé plpython.so (des extensions différentes sont possibles), alors tout va pour le mieux. Sinon, vous devriez avoir vu un avertissement semblable à : *** Cannot build PL/Python because libpython is not a shared library. *** You might have to rebuild your Python installation. Refer to *** the documentation for details. Ce qui signifie que vous devez recompiler Pythonâ„¢ (ou une partie) pour activer cette bibliothèque partagée. Si vous avez des problèmes, lancez le configure de Pythonâ„¢ 2.3 ou d'une version suivante en utilisant le commutateur --enable-shared. Sur certains systèmes d'exploitation, vous n'avez pas besoin de construire une bibliothèque partagée mais vous devrez convaincre le système de construction de PostgreSQLâ„¢ sur ce point. Consultez le fichier Makefile dans le répertoire src/pl/plpython pour des détails supplémentaires. * Si vous voulez construire le langage de procédure PL/Tcl, vous avez besoin que Tcl soit installé. * Pour activer le support de langage natif (NLS), qui permet d'afficher les messages dans une langue autre que l'anglais, vous avez besoin d'une implémentation de l'API Gettext. Certains systèmes d'exploitation l'ont intégré (par exemple, Linux, NetBSD, Solaris). Pour les autres systèmes, vous pouvez télécharger les paquetages nécessaires sur http:// developer.postgresql.org/~petere/bsd-gettext. Si vous utilisez l'implémentation de Gettext des bibliothèques C GNU, vous devrez en plus utiliser le paquetage GNU Gettextâ„¢ pour certains utilitaires. Pour toutes les autres implémentations, vous n'en avez pas besoin. * Kerberos, OpenSSLâ„¢, OpenLDAPâ„¢ ou PAM si vous voulez une authentification ou un chiffrement en utilisant ces services. Si vous compilez à partir d'une arborescence Gitâ„¢ au lieu d'utiliser un paquetage contenant les sources, ou si vous faites du développement au niveau serveur, vous aurez aussi besoin des paquetages suivants : * GNU Flex et Bison sont nécessaires pour compiler à partir d'une récupération du Git ou si vous modifiez les fichiers de recherche et d'analyse. Si vous en avez besoin, vérifiez que vous avez Flex 2.5.4 ou postérieur et Bison 1.875 ou postérieur. D'autres programmes yacc peuvent parfois d'être utilisés, ce qui n'est pas recommandé vu les efforts supplémentaires que cela demande. D'autres programmes lex ne fonctionneront définitivement pas. Si vous avez besoin de paquetages GNU, vous pourrez les trouver sur un site miroir de GNU (voir http://www.gnu.org/order/ftp.html pour en avoir la liste) ou sur ftp://ftp.gnu.org/gnu/. Vérifiez aussi que vous avez assez d'espace disque de disponible. Il vous faudra 65 Mo pour l'espace de compilation et 15 Mo pour le répertoire d'installation. Une base de données vide en cluster nécessite 25 Mo, les fichiers de la base prenant cinq fois plus d'espace que des fichiers texte contenant les mêmes données. Si vous voulez faire des tests de régression, vous aurez besoin temporairement de 90 Mo supplémentaires. Utilisez la commande df pour vérifier l'espace disque. 1.3. Si vous effectuez une mise à jour Le format de stockage interne des données a changé avec cette nouvelle version de PostgreSQLâ„¢. Toutefois, si vous faites une mise à jour qui n'a pas un numéro de version de la forme « 8.2.x », vous devrez faire une sauvegarde et une restauration des données ainsi que c'est montré ici. Les instructions considèrent que votre installation existante est dans le répertoire /usr/local/pgsql et que la zone de données est dans /usr/local/ pgsql/data. Remplacez les chemins de façon approprié. 1. Assurez-vous que vos données ne sont pas mises à jour pendant ou après la sauvegarde. Cela n'affecterait en rien l'intégrité de la sauvegarde mais les données modifiées ne seraient pas incluses. Si nécessaire, éditez le fichier /usr/local/pgsql/data/pg_hba.conf (ou équivalent) pour verrouiller tous les accès sauf les vôtres. 2. Pour effectuer une sauvegarde de votre base, saisissez : pg_dumpall > fichierdesortie Si vous souhaitez conserver les identifiants d'objets (lorsqu'ils sont utilisés comme clé étrangère), utilisez l'option -o lors de l'exécution de pg_dumpall. Pour effectuer une sauvegarde, vous pouvez exécuter la commande pg_dumpall incluse dans la distribution de votre version actuelle. Cependant, pour de meilleurs résultats, essayez d'utiliser la commande pg_dumpall contenue dans PostgreSQLâ„¢ 8.2.23 puisqu'elle corrige les erreurs des versions précédentes. Ce conseil est absurde tant que vous n'avez pas encore installé la nouvelle version. Il devient valable si vous souhaitez installer la nouvelle version en parallèle. Dans ce cas, vous pouvez faire l'installation normalement et ne transférer les données qu'après, ce qui réduira le temps d'indisponibilité. 3. Si vous installez la nouvelle version à la place de l'ancienne, arrêtez l'ancien serveur, au plus tard avant d'installer les nouveaux fichiers : pg_ctl stop Sur les systèmes qui lancent PostgreSQLâ„¢ au démarrage, il y a probablement un fichier de démarrage qui peut faire la même chose. Par exemple, sur un système Red Hat Linux, la commande /etc/rc.d/init.d/postgresql stop devrait fonctionner. Une autre possibilité est pg_ctl stop. 4. Si vous faites l'installation au même endroit que l'ancienne, il peut être une bonne idée de déplacer l'ancienne version au cas où vous auriez des problèmes et que vous ayez besoin de revenir en arrière. Utilisez une commande telle que : mv /usr/local/pgsql /usr/local/pgsql.old Après l'installation de PostgreSQLâ„¢ 8.2.23, créez un répertoire pour les données et démarrez le nouveau serveur. Rappelez-vous que vous devez exécuter ces commandes en étant connecté avec l'utilisateur dédié à la base (qui doit déjà exister si vous changez juste de version). /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data Enfin, restaurez vos données avec /usr/local/pgsql/bin/psql -d postgres -f outputfile en utilisant le nouveau psql. Des informations supplémentaires apparaissent dans la documentation que vous êtes encouragés à lire dans tous les cas. 1.4. Procédure d'installation 1. Configuration La première étape de la procédure d'installation est de configurer votre arborescence système et de choisir les options qui vous intéressent. Ce qui est fait en exécutant le script configure. Pour une installation par défaut, entrez simplement ./configure Ce script exécutera de nombreux tests afin de déterminer les valeurs de certaines variables dépendantes du système et de détecter certains aléas relatifs à votre système d'exploitation. Il créera divers fichiers dans l'arborescence de compilation pour enregistrer ce qui a été trouvé (vous pouvez aussi exécuter configure à partir d'un répertoire hors de l'arborescence des sources si vous voulez conserver l'arborescence de compilation séparé). La configuration par défaut compilera le serveur et les utilitaires, aussi bien que toutes les applications clientes et interfaces qui requièrent seulement un compilateur C. Tous les fichiers seront installés par défaut sous /usr/local/pgsql. Vous pouvez personnaliser les processus de compilation et d'installation en mettant une ou plusieurs options sur la ligne de commande après configure : --prefix=PREFIX Installe tous les fichiers dans le répertoire PREFIX au lieu du répertoire /usr/local/pgsql. Les fichiers actuels seront installés dans divers sous-répertoires ; aucun fichier ne sera directement installés sous PREFIX. Si vous avez des besoins spécifiques, vous pouvez personnaliser les sous-répertoires à l'aide des options suivantes. Néanmoins, si vous les laissez vide avec leurs valeurs par défaut, l'installation sera déplaçable, ce qui signifie que vous pourrez bouger le répertoire après installation (les emplacements de man et doc ne sont pas affectés par ceci). Pour les installations déplaçables, vous pourriez vouloir utiliser l'option --disable-rpath de configure. De plus, vous aurez besoin d'indiquer au système d'exploitation comment trouver les bibliothèques partagées. --exec-prefix=EXEC-PREFIX Vous pouvez installer les fichiers dépendants de l'architecture dans un répertoire différent, EXEC-PREFIX, de celui donné par PREFIX. Ce qui peut être utile pour partager les fichiers dépendants de l'architecture entre plusieurs machines. Si vous l'omettez, EXEC-PREFIX est égal à PREFIX et les fichiers dépendants seront installés sous la même arborescence que les fichiers indépendants de l'architecture, ce qui est probablement ce que vous voulez. --bindir=REPERTOIRE Spécifie le répertoire des exécutables. Par défaut, il s'agit de EXEC-PREFIX/bin, ce qui signifie /usr/local/pgsql/bin. --datadir=REPERTOIRE Prépare le répertoire pour des fichiers de données en lecture seule utilisés par les programmes d'installation. Par défaut, il s'agit de PREFIX/share. Il est bon de noter que cela n'a rien à voir avec l'emplacement des fichiers de votre base de données. --sysconfdir=REPERTOIRE Le répertoire contenant divers fichiers de configuration. Par défaut, il s'agit de PREFIX/etc. --libdir=REPERTOIRE L'endroit où installer les bibliothèques et les modules chargeables dynamiquement. Par défaut, il s'agit de EXEC-PREFIX/ lib. --includedir=REPERTOIRE Le répertoire où sont installées les en-têtes C et C++. Par défaut, il s'agit de PREFIX/include. --mandir=REPERTOIRE Les pages man fournies avec PostgreSQLâ„¢ seront installées sous ce répertoire, dans leur sous-répertoire manx respectif. Par défaut, il s'agit de PREFIX/man. --with-docdir=REPERTOIRE, --without-docdir Les fichiers de documentation, sauf les pages « man », seront installés dans ce répertoire. Par défaut, il s'agit de PREFIX/ doc. Si l'option --without-docdir est spécifiée, la documentation ne sera pas installée par make install. Ceci est fait pour aider les scripts d'empaquetage ayant des méthodes particulières pour installer la documentation. Note Une attention toute particulière a été prise afin de rendre possible l'installation de PostgreSQLâ„¢ dans des répertoires partagés (comme / usr/local/include) sans interférer avec des noms de fichiers relatifs au reste du système. En premier lieu, le mot « /postgresql » est automatiquement ajouté au répertoire datadir, sysconfdir et docdir, à moins que le nom du répertoire à partir de la racine contienne déjà le mot « postgres » où « pgsql ». Par exemple, si vous choisissez /usr/ local comme préfixe, la documentation sera installée dans /usr/local/ doc/postgresql, mais si le préfixe est /opt/postgres, alors il sera dans /opt/postgres/doc. Les fichiers d'en-têtes publiques C de l'interface cliente seront installés sous includedir et sont propres par rapport aux noms de fichiers relatifs au reste du système. Les fichiers d'en-têtes privés et les fichiers d'en-têtes du serveur sont installés dans des répertoires privés sous includedir. Voir la documentation de chaque interface pour savoir comment obtenir ces fichiers d'en-tête. Enfin, un répertoire privé sera aussi créé si nécessaire sous libdir pour les modules chargeables dynamiquement. --with-includes=REPERTOIRES REPERTOIRES est une liste de répertoires séparés par des caractères deux points (:) qui sera ajoutée à la liste de recherche des fichiers d'en-tête. Si vous avez des paquetages optionnels (tels que Readline GNU) installés dans des répertoires non conventionnels, vous pouvez utiliser cette option et certainement l'option --with-libraries correspondante. Exemple : --with-includes=/opt/gnu/include:/usr/sup/include. --with-libraries=REPERTOIRES REPERTOIRES est une liste de recherche de répertoires de bibliothèques séparés par des caractères deux points (:). Vous aurez probablement à utiliser cette option (et l'option correspondante --with-includes) si vous avez des paquetages installés dans des répertoires non conventionnels. Exemple : --with-libraries=/opt/gnu/lib:/usr/sup/lib. --enable-nls[=LANGUES] Permet de mettre en place le support des langues natives (NLS). C'est la possibilité d'afficher les messages des programmes dans une langue autre que l'anglais. LANGUE est une liste de codes des langues que vous voulez supporter séparés par un espace. Par exemple, --enable-nls='de fr' (l'intersection entre votre liste et l'ensemble des langues traduites actuellement sera calculée automatiquement). Si vous ne spécifiez pas de liste, alors toutes les traductions disponibles seront installées. Pour utiliser cette option, vous avez besoin d'une implémentation de l'API Gettext ; voir après. --with-pgport=NUMERO Positionne NUMERO comme numéro de port par défaut pour le serveur et les clients. La valeur par défaut est 5432. Le port peut toujours être changé ultérieurement mais, si vous le faites ici, alors les exécutables du serveur et des clients auront la même valeur par défaut, ce qui est vraiment très pratique. Habituellement, la seule bonne raison de choisir une valeur autre que celle par défaut est que vous souhaitez exécuter plusieurs serveurs PostgreSQLâ„¢ sur la même machine. --with-perl Permet l'utilisation du langage de procédures PL/Perl côté serveur. --with-python Permet la compilation du langage de procédures PL/Python. --with-tcl Permet la compilation du langage de procédures PL/Tcl. --with-tclconfig=REPERTOIRE Tcl installe les fichiers tclConfig.sh, contenant certaines informations de configuration nécessaires pour compiler le module d'interfaçage avec Tcl. Ce fichier est trouvé automatiquement mais, si vous voulez utiliser une version différente de Tcl, vous pouvez spécifier le répertoire où le trouver. --with-krb5 Compile le support d'authentification de Kerberos 5. Sur beaucoup de systèmes, le système Kerberos n'est pas installé à un emplacement recherché par défaut (c'est-à -dire /usr/include, / usr/lib), donc vous devez utiliser les options --with-includes et -- with-libraries en plus de cette option. configure vérifiera les fichiers d'en-tête et les bibliothèques requis pour s'assurer que votre installation Kerberos est suffisante avant de continuer --with-krb-srvnam=NOM Le nom par défaut du service principal de Kerberos. postgres est pris par défaut. Il n'y a habituellement pas de raison de le changer. --with-openssl Compile le support de connexion SSL (chiffrement). Le paquetage OpenSSLâ„¢ doit être installé. configure vérifiera que les fichiers d'en-tête et les bibliothèques soient installés pour s'assurer que votre installation d'OpenSSLâ„¢ est suffisante avant de continuer. --with-pam Compile le support PAM (Modules d'Authentification Pluggable). --with-ldap Demande l'ajout du support de LDAP pour l'authentification et la recherche des paramètres de connexion (voir la documentation sur l'authentification des clients et libpq). Sur Unix, cela requiert l'installation du paquet OpenLDAPâ„¢. configure vérifiera l'existence des fichiers d'en-tête et des bibliothèques requis pour s'assurer que votre installation d'OpenLDAPâ„¢ est suffisante avant de continuer. Sur Windows, la bibliothèque WinLDAPâ„¢ est utilisée par défaut. --without-readline Évite l'utilisation de la bibliothèque Readline (et de celle de libedit). Cela désactive l'édition de la ligne de commande et l'historique dans psql, ce n'est donc pas recommandé. --with-libedit-preferred Favorise l'utilisation de la bibliothèque libedit (sous licence BSD) plutôt que Readline (GPL). Cette option a seulement un sens si vous avez installé les deux bibliothèques ; dans ce cas, par défaut, Readline est utilisé. --with-bonjour Compile le support de Bonjour. Ceci requiert le support de Bonjour dans votre système d'exploitation. Recommandé sur Mac OS X. --enable-integer-datetimes Utilise le stockage des entiers sur 64 bits pour les types datetime et interval plutôt que le stockage par défaut en virgule flottante. Ceci réduit le nombre de valeurs représentatives mais garantit une précision à la microseconde sur toute l'échelle de valeurs (voir la la documentation sur les types de données date et heure pour plus d'informations). Notez aussi que le code de datetime au format entier est plus récent que celui au format en virgule flottante et que nous découvrons encore des bogues de temps en temps. --disable-spinlocks Autorise le succès de la construction y compris lorsque PostgreSQLâ„¢ n'a pas le support spinlock du CPU pour la plateforme. Ce manque de support résultera en des performances faibles ; du coup, cette option devra seulement être utilisée si la construction échoue et vous informe du manque de support de spinlock sur votre plateforme. Si cette option est requise pour construire PostgreSQLâ„¢ sur votre plateforme, merci de rapporter le problème aux développeurs de PostgreSQLâ„¢. --enable-thread-safety Rend les bibliothèques clientes compatibles avec les threads. Ceci permet des threads concurrents dans les programmes libpq et ECPG ce qui leur permet de gérer en toute sûreté leur connexions privées. Cette option requiert un support adéquat des threads sur votre système d'exploitation. --without-zlib Évite l'utilisation de la bibliothèque Zlib. Cela désactive le support des archives compressées dans pg_dump et pg_restore. Cette option est seulement là pour les rares systèmes qui ne disposent pas de cette bibliothèque. --enable-debug Compile tous les programmes et bibliothèques en mode de débogage. Cela signifie que vous pouvez exécuter les programmes via un débogueur pour analyser les problèmes. Cela grossit considérablement la taille des exécutables et, avec des compilateurs autres que GCC, habituellement, cela désactive les optimisations du compilateur, provoquant des ralentissements. Cependant, mettre ce mode en place est extrêmement utile pour repérer les problèmes. Actuellement, cette option est recommandée pour les installations en production seulement si vous utilisez GCC. Néanmoins, vous devriez l'utiliser si vous développez ou si vous utilisez une version béta. --enable-cassert Permet la vérification des assertions par le serveur qui teste de nombreux cas de conditions « impossibles ». Ce qui est inestimable dans le cas de développement, mais les tests ralentissent le système. Activer cette option n'influe pas sur la stabilité de votre serveur ! Les assertions vérifiées ne sont pas classées par ordre de sévérité et il se peut qu'un bogue anodin fasse redémarrer le serveur s'il y a un échec de vérification. Actuellement, cette option n'est pas recommandée dans un environnement de production mais vous devriez l'utiliser lors de développement ou pour les versions béta. --enable-depend Active la recherche automatique des dépendances. Avec cette option, les fichiers makefile sont appelés pour recompiler les fichiers objet dès qu'un fichier d'en-tête est modifié. C'est pratique si vous faites du développement, mais inutile si vous ne voulez que compiler une fois et installer. Pour le moment, cette option ne fonctionne qu'avec GCC. --enable-dtrace Compile avec le support de l'outil de trace dynamique, DTrace. Le seul système d'exploitation supportant DTrace pour l'instant est Solaris. Pour pointer vers le programme dtrace, la variable d'environnement DTRACE doit être configurée. Ceci sera souvent nécessaire car dtrace est typiquement installé sous /usr/sbin, qui pourrait ne pas être dans le chemin. Des options supplémentaires en ligne de commande peuvent être indiquées dans la variable d'environnement DTRACEFLAGS pour le programme dtrace. Pour inclure le support de DTrace dans un exécutable 64-bit, ajoutez l'option DTRACEFLAGS="-64" pour configure. Par exemple, en utilisant le compilateur GCC : ./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ... En utilisant le compilateur de Sun : ./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable- dtrace DTRACEFLAGS='-64' ... Si vous préférez utiliser un compilateur C différent de ceux listés par configure, positionnez la variable d'environnement CC pour qu'elle pointe sur le compilateur de votre choix. Par défaut, configure pointe sur gcc s'il est disponible, sinon il utilise celui par défaut de la plateforme (habituellement cc). De façon similaire, vous pouvez repositionner les options par défaut du compilateur à l'aide de la variable CFLAGS. Vous pouvez spécifier les variables d'environnement sur la ligne de commande configure, par exemple : ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe' Voici une liste des variables importantes qui sont configurables de cete façon : CC compilateur C CFLAGS options à passer au compilateur C CPP préprocesseur C CPPFLAGS options à passer au préprocesseur C DTRACE emplacement du programme dtrace DTRACEFLAGS options à passer au programme dtrace LDFLAGS options à passer à l'éditeur de liens LDFLAGS_SL options de l'éditeur de liens pour la création des liens des bibliothèques partagées MSGFMT programme msgfmt pour le support des langues PERL chemin complet vers l'interpréteur Perl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Perl. PYTHON chemin complet vers l'interpréteur Python. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Python. TCLSH chemin complet vers l'interpréteur Tcl. Il sera utilisé pour déterminer les dépendances pour la construction de PL/Tcl. YACC programme Yacc (bison -y si utilisation de Bison) 2. Compilation Pour démarrer la compilation, saisissez gmake (Rappelez-vous d'utiliser GNU make). La compilation peut prendre entre cinq minutes et une demi-heure en fonction de votre matériel. La dernière ligne affichée devrait être All of PostgreSQL is successfully made. Ready to install. 3. Tests de régression Si vous souhaitez tester le serveur nouvellement compileé avant de l'installer, vous pouvez exécuter les tests de régression à ce moment. Les tests de régression sont une suite de tests qui vérifient que PostgreSQLâ„¢ fonctionne sur votre machine tel que les développeurs l'espèrent. Saisissez gmake check (cela ne fonctionne pas en tant que root ; faites-le en tant qu'utilisateur sans droits). Le fichier src/test/regress/README et la documentation contiennent des détails sur l'interprétation des résultats de ces tests. Vous pouvez les répéter autant de fois que vous le voulez en utilisant la même commande. 4. Installer les fichiers Note Si vous mettez à jour une version existante et que vous placez les fichiers au même endroit que les anciens, assurez-vous d'avoir sauvegardé vos données et arrêté l'ancien serveur avant de continuer, comme l'explique la Section_1.3,_«_Si_vous_effectuez_une_mise_Ã__jour_» ci-après. Pour installer PostgreSQLâ„¢, saisissez gmake install Cela installera les fichiers dans les répertoires spécifiés dans l'Étape_1. Assurez-vous d'avoir les droits appropriés pour écrire dans ces répertoires. Normalement, vous avez besoin d'être superutilisateur pour cette étape. Une alternative consiste à créer les répertoires cibles à l'avance et à leur donner les droits appropriées. Vous pouvez utiliser gmake install-strip en lieu et place de gmake install pour dépouiller l'installation des exécutables et des bibliothèques. Cela économise un peu d'espace disque. Si vous avez effectué la compilation en mode de débogage, ce dépouillage l'enlèvera, donc ce n'est à faire seulement si ce mode n'est plus nécessaire. install-strip essaie d'être raisonnable en sauvegardant de l'espace disque mais il n'a pas une connaissance parfaite de la façon de dépouiller un exécutable de tous les octets inutiles. Ainsi, si vous voulez sauvegarder le maximum d'espace disque, vous devrez faire le travail à la main. L'installation standard fournit seulement les fichiers en-têtes nécessaires pour le développement d'applications clientes ainsi que pour le développement de programmes côté serveur comme des fonction personnelles ou des types de données écrits en C (avant PostgreSQLâ„¢ 8.0, une commande gmake install-all-headers séparée était nécessaire pour ce dernier point mais cette étape a été intégrée à l'installation standard). Installation du client uniquement : Si vous voulez uniquement installer les applications clientes et les bibliothèques d'interface, alors vous pouvez utilisez ces commandes : gmake -C src/bin install gmake -C src/include install gmake -C src/interfaces install gmake -C doc install src/bin comprend quelques exécutables utilisés seulement par le serveur mais ils sont petits. Enregistrer eventlog sur Windows : Pour enregistrer une bibliothèque eventlog sur Windows grâce au système d'exploitation, exécutez cette commande après l'installation : regsvr32 pgsql_library_directory/pgevent.dll Ceci crée les entrées du registre utilisées par le visualisateur d'événements. Désinstallation : Pour désinstaller, utilisez la commande gmake uninstall. Cependant, cela ne supprimera pas les répertoires créés. Ménage : Après l'installation, vous pouvez faire le ménage en supprimant les fichiers issus de la compilation des répertoires sources à l'aide de la commande gmake clean. Cela conservera les fichiers créés par la commande configure, ainsi vous pourrez tout recompiler ultérieurement avec gmake. Pour remettre l'arborescence source dans l'état initial, utilisez gmake distclean. Si vous voulez effectuer la compilation pour diverses plateformes à partir des mêmes sources vous devrez d'abord refaire la configuration à chaque fois (autrement, utilisez un répertoire de construction séparé pour chaque plateforme, de façon à ce que le répertoire des sources reste inchangé). Si vous avez compilé et que vous vous êtes rendu compte que les options de configure sont fausses ou si vous changez quoique ce soit que configure prenne en compte (par exemple, la mise à jour d'applications), alors faire un gmake distclean avant de reconfigurer et recompiler est une bonne idée. Sans ça, vos changements dans la configuration ne seront pas répercutés partout où il faut. 1.5. Initialisation post-installation 1.5.1. Bibliothèques partagées Sur certains systèmes qui utilisent les bibliothèques partagées (ce que font de nombreux systèmes), vous avez besoin de leurs spécifier comment trouver les nouvelles bibliothèques partagées. Les systèmes sur lesquels ce n'est pas nécessaire comprennent BSD/OS, FreeBSD, HP-UX, IRIX, Linux, NetBSD, OpenBSD, Tru64 UNIX (auparavant Digital UNIX) et Solaris. La méthode pour le faire varie selon la plateforme, mais la méthode la plus répandue consiste à positionner des variables d'environnement comme LD_LIBRARY_PATH : avec les shells Bourne (sh, ksh, bash, zsh) LD_LIBRARY_PATH=/usr/local/pgsql/lib export LD_LIBRARY_PATH ou en csh ou tcsh setenv LD_LIBRARY_PATH /usr/local/pgsql/lib Remplacez /usr/local/pgsql/lib par la valeur donnée à --libdir dans l'Étape 1. Vous pouvez mettre ces commandes dans un script de démarrage tel que /etc/ profile ou ~/.bash_profile. Certaines informations pertinentes au sujet de mises en garde associées à cette méthode peuvent être trouvées sur http:// www.visi.com/~barr/ldpath.html. Sur certains systèmes, il peut être préférable de renseigner la variable d'environnement LD_RUN_PATH avant la compilation. Avec Cygwin, placez le répertoire des bibliothèques dans la variable PATH ou déplacez les fichiers .dll dans le répertoire bin. En cas de doute, référez-vous aux pages de man de votre système (peut-être ld.so ou rld). Si vous avez ultérieurement un message tel que psql: error in loading shared libraries libpq.so.2.1: cannot open shared object file: No such file or directory alors cette étape est vraiment nécessaire. Faites-y attention. Si votre système d'exploitation est BSD/OS, Linux ou SunOS 4 et que vous avez les accès de superutilisateur, vous pouvez exécuter /sbin/ldconfig /usr/local/pgsql/lib (ou le répertoire équivalent) après l'installation pour permettre à l'éditeur de liens de trouver les bibliothèques partagées plus rapidement. Référez-vous aux pages man portant sur ldconfig pour plus d'informations. Pour les systèmes d'exploitation FreeBSD, NetBSD et OpenBSD, la commande est /sbin/ldconfig -m /usr/local/pgsql/lib Les autres systèmes d'exploitation ne sont pas connus pour avoir de commande équivalente. 1.5.2. Variables d'environnement Si l'installation a été réalisée dans /usr/local/pgsql ou à un autre endroit qui n'est pas dans les répertoires contenant les exécutables par défaut, vous devez ajouter /usr/local/pgsql/bin (ou le répertoire fourni à - -bindir au moment de l'Étape_1) dans votre PATH. Techniquement, ce n'est pas une obligation mais cela rendra l'utilisation de PostgreSQLâ„¢ plus confortable. Pour ce faire, ajoutez ce qui suit dans le fichier d'initialisation de votre shell, par exemple ~/.bash_profile (ou /etc/profile, si vous voulez que tous les utilisateurs l'aient) : PATH=/usr/local/pgsql/bin:$PATH export PATH Si vous utilisez le csh ou le tcsh, alors utilisez la commande : set path = ( /usr/local/pgsql/bin $path ) Pour que votre système trouve la documentation man, il vous faut ajouter des lignes telles que celles qui suivent à votre fichier d'initialisation du shell, à moins que vous installiez ces pages dans un répertoire où elles sont mises normalement. MANPATH=/usr/local/pgsql/man:$MANPATH export MANPATH Les variables d'environnement PGHOST et PGPORT indiquent aux applications clientes l'hôte et le port du serveur de base. Elles surchargent les valeurs utilisées lors de la compilation. Si vous exécutez des applications clientes à distance, alors c'est plus pratique si tous les utilisateurs peuvent paramétrer PGHOST. Ce n'est pas une obligation, cependant, la configuration peut être communiquée via les options de lignes de commande à la plupart des programmes clients. 1.6. Démarrer La suite est un résumé rapide de la façon de faire fonctionner PostgreSQLâ„¢ une fois l'installation terminée. La documentation principale contient plus d'informations. 1. Créer un compte utilisateur pour le serveur PostgreSQLâ„¢. C'est cet utilisateur qui fera démarrer le serveur. Pour un usage en production, vous devez créer un compte sans droits (« postgres » est habituellement utilisé). Si vous n'avez pas les accès superutilisateur ou si vous voulez juste regarder, votre propre compte utilisateur est suffisant. Mais, utiliser le compte superutilisateur pour démarrer le serveur est risqué (au point de vue sécurité) et ne fonctionnera pas. adduser postgres 2. Faire l'installation de la base de données avec la commande initdb. Pour exécuter initdb, vous devez être connecté sur votre serveur avec le compte PostgreSQLâ„¢. Cela ne fonctionnera pas avec le compte superutilisateur. root# mkdir /usr/local/pgsql/data root# chown postgres /usr/local/pgsql/data root# su - postgres postgres$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data L'option -D spécifie le répertoire où les données seront stockées. Vous pouvez utiliser le chemin que vous voulez, il n'a pas à être sous le répertoire de l'installation. Avant de lancer initdb, assurez-vous que le compte serveur peut écrire dans ce répertoire (ou le créer s'il n'existe pas), comme c'est montré ici. 3. L'étape précédente vous a indiqué comment démarrer le serveur de base. Maintenant, faites-le. La commande doit ressembler à /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data Cela démarrera le serveur en avant-plan. Pour le mettre en arrière plan faites quelque chose comme nohup /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data \ >server.log 2>&1 et non aux personnes listées dans ce document. __________________________________________________________________________________ |Système |Processeur|Version|Date du rapport |Remarques | |d'exploitation|__________|_______|______________________________|_________________| | | | |Fermes de construction grebe |Voir doc/FAQ_AIX,| | | | |(5.3, gcc 4.0.1) ; kookaburra |tout | |AIX |PowerPC |8.2.0 |(5.2, cc 6.0) ; asp (5.2, gcc |particulièrement| | | | |3.3.2) |si vous utilisez | |______________|__________|_______|______________________________|AIX_5.3_ML3______| |AIX |RS6000 |8.0.0 |Hans-Jürgen Schönig |Voir doc/FAQ_AIX | |______________|__________|_______|(),_2004-12-06|_________________| | | | |Bruce Momjian | | |BSD/OS |x86 |8.1.0 |(), |4.3.1 | |______________|__________|_______|2005-10-26____________________|_________________| |Debian GNU/ |Alpha |8.2.0 |Ferme de construction hare | | |Linux_________|__________|_______|(3.1,_gcc_3.3.4)______________|_________________| | | | |Fermes de construction shad | | |Debian GNU/ |AMD64 |8.2.0 |(4.0, gcc 4.1.2); kite (3.1, | | |Linux | | |gcc 4.0); panda (sid, gcc | | |______________|__________|_______|3.3.5)________________________|_________________| |Debian GNU/ |ARM |8.2.0 |Ferme de construction penguin | | |Linux_________|__________|_______|(3.1,_gcc_3.3.4)______________|_________________| |Debian GNU/ |Athlon XP |8.2.0 |Ferme de construction rook | | |Linux_________|__________|_______|(3.1,_gcc_3.3.5)______________|_________________| |Debian GNU/ |IA64 |8.2.0 |Ferme de construction dugong | | |Linux_________|__________|_______|(unstable,_icc_9.1.045)_______|_________________| |Debian GNU/ | | |Noèl Köthe | | |Linux |m68k |8.0.0 |(), 2004-12- |sid | |______________|__________|_______|09____________________________|_________________| |Debian GNU/ |MIPS |8.2.0 |Ferme de construction otter | | |Linux_________|__________|_______|(3.1,_gcc_3.3.4)______________|_________________| |Debian GNU/ | | |Fermes de construction | | |Linux |MIPSEL |8.2.0 |lionfish (3.1, gcc 3.3.4); | | |______________|__________|_______|corgi_(3.1,_gcc_3.3.4)________|_________________| |Debian GNU/ | | |Fermes de construction manatee| | |Linux |PA-RISC |8.2.0 |(3.1, gcc 4.0.1); kingfisher | | |______________|__________|_______|(3.1,_gcc_3.3.5)______________|_________________| |Debian GNU/ | | |Noèl Köthe | | |Linux |PowerPC |8.0.0 |(), 2004-12- |sid | |______________|__________|_______|15____________________________|_________________| |Debian GNU/ |Sparc |8.1.0 |Ferme de construction dormouse| | |Linux_________|__________|_______|(3.1,_gcc_3.2.5;_64-bit)______|_________________| |Debian GNU/ |x86 |8.2.0 |Ferme de construction | | |Linux_________|__________|_______|wildebeest_(3.1,_gcc_3.3.5)___|_________________| | | | |Fermes de construction impala | | | | | |(FC6, gcc 4.1.1); bustard | | |Fedora Linux |AMD64 |8.2.0 |(FC5, gcc 4.1.0); wasp (FC5, | | | | | |gcc 4.1.0); viper (FC3, gcc | | |______________|__________|_______|3.4.4)________________________|_________________| |Fedora Linux |PowerPC |8.2.0 |Ferme de construction sponge | | |______________|__________|_______|(FC5,_gcc_4.1.0)______________|_________________| | | | |Fermes de construction agouti | | |Fedora Linux |x86 |8.2.0 |(FC5, gcc 4.1.1); thrush (FC1,| | |______________|__________|_______|gcc_3.3.2)____________________|_________________| | | | |Fermes de construction | | |FreeBSD |AMD64 |8.2.0 |platypus (6, gcc 3.4.4); dove | | | | | |(6.1, gcc 3.4.4); ermine (6.1,| | |______________|__________|_______|gcc_3.4.4)____________________|_________________| | | | |Fermes de construction minnow | | |FreeBSD |x86 |8.2.0 |(6.1, gcc 3.4.4); echidna (6, | | | | | |gcc 3.4.2); herring (6, Intel | | |______________|__________|_______|cc_7.1)_______________________|_________________| |Gentoo Linux |AMD64 |8.1.0 |Ferme de construction caribou | | |______________|__________|_______|(2.6.9,_gcc_3.3.5)____________|_________________| |Gentoo Linux |IA64 |8.2.0 |Ferme de construction stoat | | |______________|__________|_______|(2.6,_gcc_3.3)________________|_________________| |Gentoo Linux |PowerPC 64|8.2.0 |Ferme de construction cobra | | |______________|__________|_______|(1.4.16,_gcc_3.4.3)___________|_________________| |Gentoo Linux |x86 |8.2.0 |Ferme de construction mongoose| | |______________|__________|_______|(1.6.14,_icc_9.0.032)_________|_________________| | | | |Tom Lane |11.23, gcc et cc | |HP-UX |IA64 |8.2.0 |(), 2006- |; voir doc/ | |______________|__________|_______|10-23_________________________|FAQ_HPUX_________| | | | |Tom Lane |10.20 and 11.23, | |HP-UX |PA-RISC |8.2.0 |(), 2006- |gcc et cc ; voir | |______________|__________|_______|10-23_________________________|doc/FAQ_HPUX_____| | | | |Kenneth Marshall | | |IRIX |MIPS |8.1.0 |(), 2005-11- |6.5, cc seulement| |______________|__________|_______|04____________________________|_________________| |Kubuntu Linux |AMD64 |8.2.0 |Ferme de construction rosella | | |______________|__________|_______|(5.10_«_Breezy_»,_gcc_4.0)__|_________________| |Mac OS X |PowerPC |8.2.0 |Ferme de construction tuna | | |______________|__________|_______|(10.4.2,_gcc_4.0)_____________|_________________| |Mac OS X |x86 |8.2.0 |Ferme de construction jackal | | |______________|__________|_______|(10.4.8,_gcc_4.0.1)___________|_________________| |Mandriva Linux|x86 |8.2.0 |Ferme de construction gopher | | |______________|__________|_______|(Mandriva_2006,_gcc_4.0.1)____|_________________| |NetBSD |m68k |8.2.0 |Ferme de construction osprey | | |______________|__________|_______|(2.0,_gcc_3.3.3)______________|_________________| | | | |Fermes de construction gazelle| | |NetBSD |x86 |8.2.0 |(3.0, gcc 3.3.3) ; canary | | |______________|__________|_______|(1.6,_gcc_2.95.3)_____________|_________________| |OpenBSD |AMD64 |8.2.0 |Ferme de construction zebra | | |______________|__________|_______|(4.0,_gcc_3.3.5)______________|_________________| |OpenBSD |Sparc |8.0.0 |Chris Mair (), |3.3 | |______________|__________|_______|2005-01-10____________________|_________________| |OpenBSD |Sparc64 |8.2.0 |Ferme de construction | | |______________|__________|_______|spoonbill_(3.9,_gcc_3.3.5)____|_________________| | | | |Fermes de construction emu |minor ecpg test | |OpenBSD |x86 |8.2.0 |(4.0, gcc 3.3.5) ; guppy (3.8,|failure on 3.8 | |______________|__________|_______|gcc_3.3.5)____________________|_________________| | | | |Tom Lane | | |Red Hat Linux |AMD64 |8.1.0 |(), 2005- |RHEL 4 | |______________|__________|_______|10-23_________________________|_________________| | | | |Tom Lane | | |Red Hat Linux |IA64 |8.1.0 |(), 2005- |RHEL 4 | |______________|__________|_______|10-23_________________________|_________________| | | | |Tom Lane | | |Red Hat Linux |PowerPC |8.1.0 |(), 2005- |RHEL 4 | |______________|__________|_______|10-23_________________________|_________________| | | | |Tom Lane | | |Red Hat Linux |PowerPC 64|8.1.0 |(), 2005- |RHEL 4 | |______________|__________|_______|10-23_________________________|_________________| | | | |Tom Lane | | |Red Hat Linux |S/390 |8.1.0 |(), 2005- |RHEL 4 | |______________|__________|_______|10-23_________________________|_________________| | | | |Tom Lane | | |Red Hat Linux |S/390x |8.1.0 |(), 2005- |RHEL 4 | |______________|__________|_______|10-23_________________________|_________________| | | | |Tom Lane | | |Red Hat Linux |x86 |8.1.0 |(), 2005- |RHEL 4 | |______________|__________|_______|10-23_________________________|_________________| |Slackware | | |Sergey Koposov | | |Linux |x86 |8.1.0 |(), 2005-10- |10.0 | |______________|__________|_______|24____________________________|_________________| |Solaris |Sparc |8.2.0 |Ferme de construction hyena |Voir doc/ | |______________|__________|_______|(Solaris_10,_gcc_3.4.3)_______|FAQ_Solaris______| | | | |Ferme de construction | | |Solaris |x86 |8.2.0 |dragonfly (Solaris 9, gcc |Voir doc/ | | | | |3.2.3); kudu (Solaris 9, cc |FAQ_Solaris | |______________|__________|_______|5.3)__________________________|_________________| | | | |Josh Berkus | | |SUSE Linux |AMD64 |8.1.0 |(), 2005- |SLES 9.3 | |______________|__________|_______|10-23_________________________|_________________| |SUSE Linux |IA64 |8.0.0 |Reinhard Max (), |SLES 9 | |______________|__________|_______|2005-01-03____________________|_________________| |SUSE Linux |PowerPC |8.0.0 |Reinhard Max (), |SLES 9 | |______________|__________|_______|2005-01-03____________________|_________________| |SUSE Linux |PowerPC 64|8.0.0 |Reinhard Max (), |SLES 9 | |______________|__________|_______|2005-01-03____________________|_________________| |SUSE Linux |S/390 |8.0.0 |Reinhard Max (), |SLES 9 | |______________|__________|_______|2005-01-03____________________|_________________| |SUSE Linux |S/390x |8.0.0 |Reinhard Max (), |SLES 9 | |______________|__________|_______|2005-01-03____________________|_________________| |SUSE Linux |x86 |8.0.0 |Reinhard Max (), |9.0, 9.1, 9.2, | |______________|__________|_______|2005-01-03____________________|SLES_9___________| | | | |Honda Shigehiro | | |Tru64 UNIX |Alpha |8.1.0 |(),|5.0, cc 6.1-011 | |______________|__________|_______|2005-11-01____________________|_________________| |Ubuntu Linux |x86 |8.2.0 |Ferme de construction caracara| | |______________|__________|_______|(6.06,_gcc_4.0.3)_____________|_________________| |UnixWare |x86 |8.2.0 |Ferme de construction warthog |Voir doc/FAQ_SCO | |______________|__________|_______|(7.1.4,_cc_4.2)_______________|_________________| | | | |Fermes de construction yak (XP| | | | | |SP2, gcc 3.4.2) ; bandicoot | | | | | |(Windows 2000 Pro, gcc 3.4.2) |Voir doc/ | |Windows |x86 |8.2.0 |; snake (Windows Server 2003 |FAQ_MINGW | | | | |SP1, gcc 3.4.2) ; trout | | | | | |(Windows Server 2000 SP4, gcc | | |______________|__________|_______|3.4.2)________________________|_________________| |Windows with |x86 |8.2.0 |Ferme de construction eel (W2K|Voir doc/ | |Cygwin________|__________|_______|Server_SP4,_gcc_3.4.4)________|FAQ_CYGWIN_______| |Yellow Dog |PowerPC |8.1.0 |Ferme de construction carp | | |Linux_________|__________|_______|(4.0,_gcc_3.3.3)______________|_________________| Plateformes non supportées : Les plateformes suivantes fonctionnaient mais n'ont pas été testées récemment. Nous les plaçons ici afin de vous prévenir qu'elles peuvent être supportées avec quelques efforts. ____________________________________________________________________________ |Système |Processeur |Version|Date du rapport |Remarques | |d'exploitation|_____________|_______|_________________________|_____________| |Debian GNU/ | | |Noèl Köthe | | |Linux |S/390 |7.4 |(), | | |______________|_____________|_______|2003-10-25_______________|_____________| | | | |Peter Eisentraut | | |FreeBSD |Alpha |7.4 |(), |4.8 | |______________|_____________|_______|2003-10-25_______________|_____________| | | | | |requiert -- | | | | |Chris Mair |disable- | |Linux |PlayStation 2|8.0.0 |(), 2005- |spinlocks | | | | |01-09 |(fonctionne | | | | | |mais | |______________|_____________|_______|_________________________|lentement)___| | | | |Thomas Thai | | |NetBSD |Alpha |7.2 |(), |1.5W | |______________|_____________|_______|2001-11-20_______________|_____________| | | | |Patrick Welche | | |NetBSD |arm32 |7.4 |(),|1.6ZE/acorn32| |______________|_____________|_______|2003-11-12_______________|_____________| | | | |Warwick Hunter | | |NetBSD |MIPS |7.2.1 |(), |1.5.3 | |______________|_____________|_______|2002-06-13_______________|_____________| | | | |Bill Studenmund | | |NetBSD |PowerPC |7.2 |(), |1.5 | |______________|_____________|_______|2001-11-28_______________|_____________| | | | |Peter Eisentraut | | |NetBSD |Sparc |7.4.1 |(), |1.6.1, 32-bit| |______________|_____________|_______|2003-11-26_______________|_____________| | | | |Tom I. Helbekkmo | | |NetBSD |VAX |7.1 |(), |1.5 | |______________|_____________|_______|2001-03-30_______________|_____________| | | | |Shibashish Satpathy |5.0.4, gcc ; | |SCO OpenServer|x86 |7.3.1 |(), |voir aussi | |______________|_____________|_______|2002-12-11_______________|doc/FAQ_SCO__| | | | |Tatsuo Ishii (), 2001- | | |______________|_____________|_______|12-04____________________|_____________|