A voir également:
- Portabilité de ghostscript (pas d'install)
- Ghostscript - Télécharger - Polices de caractères
- Ghostscript Viewer - Télécharger - Polices de caractères
- Play store install - Télécharger - Téléchargement & Transfert
- Install microsoft store - Guide
- Bloatynosy install - Télécharger - Nettoyage
9 réponses
Bonjour,
Pour extraire les fichiers binaires d'un package d'installation, tout dépend de quel type de package il s'agit (quel extension??).
Mais ca m'étonnerait que tu t'en sortes simplement en récupérant les binaires, car les librairies requises ne seront pas installées sur ton système.
D'ailleurs, que veux tu dire par "j'aimerais vraiment que ghostscript ne soit pas intégré au système" ??
Cordialement, M.
Pour extraire les fichiers binaires d'un package d'installation, tout dépend de quel type de package il s'agit (quel extension??).
Mais ca m'étonnerait que tu t'en sortes simplement en récupérant les binaires, car les librairies requises ne seront pas installées sur ton système.
D'ailleurs, que veux tu dire par "j'aimerais vraiment que ghostscript ne soit pas intégré au système" ??
Cordialement, M.
Bonjour Swed,
Merci pour votre rapidité,
Vous pouvez trouver les packages ici:
https://ghostscript.com/releases/
j'ai prit le ghostscript-8.71.tar.gz
Je pense que ce qu'il propose (car je ne connais pas Linux) sont des fichiers d'installation, pour que ghostscript soit intégré au système (appelé par la commande "gs ..." dans le shell).
Mais moi, je veux qu'il soit dans un répertoire complètement autonome, qu'on appèle ghostscript depuis son fichier exécutable là ou il se trouve physiquement.
"/home/monGhostscript/fichierExe ...".
Bref, je veux utiliser ghostscript sans avoir à faire d'installation car je n'ai pas la main sur le serveur.
Ils l'ont prévus pour Windows, je pensais que ce serait simple pour Linux.
Suis je clair ? ;-)
Merci pour votre rapidité,
Vous pouvez trouver les packages ici:
https://ghostscript.com/releases/
j'ai prit le ghostscript-8.71.tar.gz
Je pense que ce qu'il propose (car je ne connais pas Linux) sont des fichiers d'installation, pour que ghostscript soit intégré au système (appelé par la commande "gs ..." dans le shell).
Mais moi, je veux qu'il soit dans un répertoire complètement autonome, qu'on appèle ghostscript depuis son fichier exécutable là ou il se trouve physiquement.
"/home/monGhostscript/fichierExe ...".
Bref, je veux utiliser ghostscript sans avoir à faire d'installation car je n'ai pas la main sur le serveur.
Ils l'ont prévus pour Windows, je pensais que ce serait simple pour Linux.
Suis je clair ? ;-)
Bonjour,
Ce que tu as téléchargé, c'est le code source de ghostscript.
Tu peux décompresser l'archive via la commande "tar-xzf tonarchive.tar"
Cette archive ne contient que des sources, pas de 'binaire'.
Il va falloir compiler pour 'générer' les 'binaires' et les librairies.
Pour compiler, le mieux est de suivre les instructions du fichier INSTALL ou README qui doit se trouver dans l'archive ; où voir la doc sur le site de ghostscript.
Tu pourras alors choisir l'emplacement où l'installer ;
Même si tu n'a pas les droits root sur la machine, tu pourras l'installer dans un rép perso où tu as les droits (par exemple ton /home/monGhostScript).
Cordialement, M.
Ce que tu as téléchargé, c'est le code source de ghostscript.
Tu peux décompresser l'archive via la commande "tar-xzf tonarchive.tar"
Cette archive ne contient que des sources, pas de 'binaire'.
Il va falloir compiler pour 'générer' les 'binaires' et les librairies.
Pour compiler, le mieux est de suivre les instructions du fichier INSTALL ou README qui doit se trouver dans l'archive ; où voir la doc sur le site de ghostscript.
Tu pourras alors choisir l'emplacement où l'installer ;
Même si tu n'a pas les droits root sur la machine, tu pourras l'installer dans un rép perso où tu as les droits (par exemple ton /home/monGhostScript).
Cordialement, M.
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
4 896
12 avril 2010 à 15:56
12 avril 2010 à 15:56
Salut,
Extrait :
Extrait :
Installing Ghostscript on Unix
Ghostscript uses the common configure, build and install method common to many modern software packages. In general the following with suffice to build ghostscript:
./configure
make
and then it may be installed in the default location with:
make install
This last command may need to be performed with super user privileges.
You can set the installation directory by adding --prefix=path to the configure invocation in the first step. The default prefix is /usr/local, which is to say the gs executable is installed as /usr/local/bin/gs.
A list of similar configuration options is available via ./configure --help
For more detailed information on building Ghostscript see how to build Ghostscript on Unix in the documentation on building Ghostscript, especially regarding information on using the older hand edited makefile approach. Whatever configuration method you use, execute "make install" to install the executable and all the required and ancillary files after the build is complete
Ok,
Il y a bien un install.html mais il y a pas mal d'instructions.
Je ne connais pas du tout Linux et je vais devoir faire tout ça à distance avec des lignes de commandes php... Ça va être gai. ;-)
Je pense qu'il doit bien y avoir ces binaires de disponibles quelque part...
Il y a bien un install.html mais il y a pas mal d'instructions.
Je ne connais pas du tout Linux et je vais devoir faire tout ça à distance avec des lignes de commandes php... Ça va être gai. ;-)
Je pense qu'il doit bien y avoir ces binaires de disponibles quelque part...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Voilà, je suis sur un live CD de mandrake (j'ai ubuntu également, s'il faut).
Il y a déjà gs d'installé.
J'ai bien trouvé le répertoire ghostscript dans /usr/share/
Seulement, il y a pas mal de fichiers dedans, mais rien qui ne ressemble à un executable.
Comment faire pour savoir vers quel fichier il pointe lorsqu'on fait une commande dans le shell.
("gs -help" appelle quel fichier ?)
Merci d'avance.
Il y a déjà gs d'installé.
J'ai bien trouvé le répertoire ghostscript dans /usr/share/
Seulement, il y a pas mal de fichiers dedans, mais rien qui ne ressemble à un executable.
Comment faire pour savoir vers quel fichier il pointe lorsqu'on fait une commande dans le shell.
("gs -help" appelle quel fichier ?)
Merci d'avance.
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
4 896
13 avril 2010 à 13:48
13 avril 2010 à 13:48
$ whereis gs gs: /usr/bin/gs /usr/share/man/man1/gs.1.bz2
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
4 896
13 avril 2010 à 14:00
13 avril 2010 à 14:00
C'est quoi le 2ème chemin ?
Le chemin vers les pages de manuels (man page)
Et tout ce qu'il y a dans "/usr/..." est ce que c'est indispensable pour faire fonctionner GS ?
Extrait de L'arborescence des fichiers :
Voir aussi L'arborescence du système de fichiers de Linux
Le chemin vers les pages de manuels (man page)
Et tout ce qu'il y a dans "/usr/..." est ce que c'est indispensable pour faire fonctionner GS ?
Extrait de L'arborescence des fichiers :
/usr/bin contient la majorité des fichiers binaires et commandes utilisateurs
Voir aussi L'arborescence du système de fichiers de Linux
Bon, j'ai copié un max de choses dans le répertoire (et en respectant l'arborescence, et en mettant tout à la racine) que j'ai collé sur le serveur et rien ne passe.
exec("./gs/gs -help");
exec("gs/gs -help");
exec("$CheminCompletDepuisLaRacine/gs/gs -help");
exec("\"./gs/gs\" -help");
Bref, j'ai tout essayé et il me renvoie toujours false. :-(
Pas moyen de rendre l'appli indépendante et portable.
C'est tout de même surprenant, c'est tellement facile sous Windows. 0_0
exec("./gs/gs -help");
exec("gs/gs -help");
exec("$CheminCompletDepuisLaRacine/gs/gs -help");
exec("\"./gs/gs\" -help");
Bref, j'ai tout essayé et il me renvoie toujours false. :-(
Pas moyen de rendre l'appli indépendante et portable.
C'est tout de même surprenant, c'est tellement facile sous Windows. 0_0
Bonjour,
Si tu fais un "ldd /ton/executable/ghostscript", tu verras la liste des librairies dont gs est dépendant. Elles sont indispensables pour le faire fonctionner.
Copier le binaire ne suffira donc probablement pas.
Désolé, mais je n'ai pas compris la raison qui t'empèche de faire l'install sur le serveur UNIX.
Cordialement, M.
Si tu fais un "ldd /ton/executable/ghostscript", tu verras la liste des librairies dont gs est dépendant. Elles sont indispensables pour le faire fonctionner.
Copier le binaire ne suffira donc probablement pas.
Désolé, mais je n'ai pas compris la raison qui t'empèche de faire l'install sur le serveur UNIX.
Cordialement, M.
Swed,
Je n'ai pas la main sur le seveur.
J'ai pensé que ta solution était exactement ce qu'il me fallait, mais il me sort tout ça:
ubuntu@ubuntu:~$ ldd /usr/bin/gs
linux-gate.so.1 => (0x001f7000)
libgs.so.8 => /usr/lib/libgs.so.8 (0x004da000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x001f8000)
libpaper.so.1 => /usr/lib/libpaper.so.1 (0x0044a000)
libcupsimage.so.2 => /usr/lib/libcupsimage.so.2 (0x00110000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x00129000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0016e000)
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x0033c000)
libz.so.1 => /lib/libz.so.1 (0x0045e000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x0019b000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x001b4000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0x003e4000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x001da000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00d57000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00416000)
/lib/ld-linux.so.2 (0x00d3a000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00474000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00e49000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00d15000)
libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0x001de000)
libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0x00e71000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00e82000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00f34000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x001ea000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x001ee000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00443000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0x00f5f000)
libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00f73000)
libgcrypt.so.11 => /lib/libgcrypt.so.11 (0x00f85000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x01a50000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x07935000)
libexpat.so.1 => /lib/libexpat.so.1 (0x03fe3000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x0522f000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x0044e000)
libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x00457000)
ubuntu@ubuntu:~$
Ca me surprend... Il ne va pas falloir que je joigne tout ça tout de même !
Les fichier *.so.*, c'est des expèces de DLL, c'est ça ?
Et comment je trouve le 1er, qui n'a pas de chemin ? J'ai fait une recherche sur racine et il ne trouve rien,
Je n'ai pas la main sur le seveur.
J'ai pensé que ta solution était exactement ce qu'il me fallait, mais il me sort tout ça:
ubuntu@ubuntu:~$ ldd /usr/bin/gs
linux-gate.so.1 => (0x001f7000)
libgs.so.8 => /usr/lib/libgs.so.8 (0x004da000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x001f8000)
libpaper.so.1 => /usr/lib/libpaper.so.1 (0x0044a000)
libcupsimage.so.2 => /usr/lib/libcupsimage.so.2 (0x00110000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x00129000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0016e000)
libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x0033c000)
libz.so.1 => /lib/libz.so.1 (0x0045e000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x0019b000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x001b4000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0x003e4000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x001da000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00d57000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00416000)
/lib/ld-linux.so.2 (0x00d3a000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00474000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00e49000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00d15000)
libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0x001de000)
libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0x00e71000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00e82000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00f34000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x001ea000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x001ee000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00443000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0x00f5f000)
libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00f73000)
libgcrypt.so.11 => /lib/libgcrypt.so.11 (0x00f85000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x01a50000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x07935000)
libexpat.so.1 => /lib/libexpat.so.1 (0x03fe3000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x0522f000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x0044e000)
libgpg-error.so.0 => /lib/libgpg-error.so.0 (0x00457000)
ubuntu@ubuntu:~$
Ca me surprend... Il ne va pas falloir que je joigne tout ça tout de même !
Les fichier *.so.*, c'est des expèces de DLL, c'est ça ?
Et comment je trouve le 1er, qui n'a pas de chemin ? J'ai fait une recherche sur racine et il ne trouve rien,
Pour le 1er fichier, qu'est ce qui se passe exactement ?
J'ai fait:
ubuntu@ubuntu:~$ ls -l linux-gate.so.1
Il me répond
ls: cannot access linux-gate.so.1: No such file or directory
Pourquoi ne se comporte t-il pas comme les autres, qu'il n'a pas de chemin ?
Sinon, pour les autres, ça fonctionne bien.
J'ai fait:
ubuntu@ubuntu:~$ ls -l linux-gate.so.1
Il me répond
ls: cannot access linux-gate.so.1: No such file or directory
Pourquoi ne se comporte t-il pas comme les autres, qu'il n'a pas de chemin ?
Sinon, pour les autres, ça fonctionne bien.
Concernant le linux-gate.so.1 ; tu peux l'ignorer ;
Ce n'est pas une dépendance ; il n'y a rien derrière la flèche ce qui veut dire que ca correspond pas à une lib de ton système... (ca apparait dans tous les ldd)
C'est cocasse, alors je ne t'explique pas ce que c'est (d'ailleurs je ne sais pas très bien).
Si tu est curieux, google pourra te renseigner.
Tu devrais aussi te renseigner sur la variable d'env LD_LIBRARY_PATH.
Lorsque tu va lancer gs, par défaut, il va aller chercher les librairies dont il dépend dans les répertoires 'standarts' du système.
Il te faudra définir LD_LIBRARY_CONFIG=/path/ou/sont/tes/libs ; pour que gs les trouve.
Cordialement, M.
Ce n'est pas une dépendance ; il n'y a rien derrière la flèche ce qui veut dire que ca correspond pas à une lib de ton système... (ca apparait dans tous les ldd)
C'est cocasse, alors je ne t'explique pas ce que c'est (d'ailleurs je ne sais pas très bien).
Si tu est curieux, google pourra te renseigner.
Tu devrais aussi te renseigner sur la variable d'env LD_LIBRARY_PATH.
Lorsque tu va lancer gs, par défaut, il va aller chercher les librairies dont il dépend dans les répertoires 'standarts' du système.
Il te faudra définir LD_LIBRARY_CONFIG=/path/ou/sont/tes/libs ; pour que gs les trouve.
Cordialement, M.
pfff, je n'avais pas mis les droit en exécution... 0_0
Maintenant, l'exécutable appelé fait bien quelque chose.
Par contre, il me dit que c'est toujours la version 8.15 et il rencontre les mêmes problèmes que la 8.15.
Pourtant, je l'appelle bien par son chemin absolu, je pointe bien vers l'exe que j'ai copié depuis la 8.7.
Pour info, il y a un version de gs installée sur le serveur, la 8.15.
Mais elle est ne fonctionne pas (si, mais que pour les très petits fichiers et encore, elle est super longue).
Même sur le UBUNTU live CD, d'ou j'ai extrait la version 8.7, j'ai fait la commande sur un fichier super lourd et ça à très bien fonctionné et très rapidement.
C'est pourquoi je voulais utiliser un fichier sur lequel j'ai la main.
Seulement, le fait de pointer vers un exe de la 8.7 avec toutes ses dépendances copiées à la racine du même répertoire n'a pas l'air de suffir.
L'exe doit trouver les chemins de ses dépendances sur le serveur et les utiliser.
Maintenant, l'exécutable appelé fait bien quelque chose.
Par contre, il me dit que c'est toujours la version 8.15 et il rencontre les mêmes problèmes que la 8.15.
Pourtant, je l'appelle bien par son chemin absolu, je pointe bien vers l'exe que j'ai copié depuis la 8.7.
Pour info, il y a un version de gs installée sur le serveur, la 8.15.
Mais elle est ne fonctionne pas (si, mais que pour les très petits fichiers et encore, elle est super longue).
Même sur le UBUNTU live CD, d'ou j'ai extrait la version 8.7, j'ai fait la commande sur un fichier super lourd et ça à très bien fonctionné et très rapidement.
C'est pourquoi je voulais utiliser un fichier sur lequel j'ai la main.
Seulement, le fait de pointer vers un exe de la 8.7 avec toutes ses dépendances copiées à la racine du même répertoire n'a pas l'air de suffir.
L'exe doit trouver les chemins de ses dépendances sur le serveur et les utiliser.
Bonjour,
"Seulement, le fait de pointer vers un exe de la 8.7 avec toutes ses dépendances copiées à la racine du même répertoire n'a pas l'air de suffir"
Comme je t'ai dit, lance gs avec cette commande :
export LD_LIBRARY_PATH=/repertoire/contenant/les/librairies && /ton/executable/gs
Il utilisera alors les librairies présentes dans le LD_LIBRARY_PATH
Cordialement, M.
"Seulement, le fait de pointer vers un exe de la 8.7 avec toutes ses dépendances copiées à la racine du même répertoire n'a pas l'air de suffir"
Comme je t'ai dit, lance gs avec cette commande :
export LD_LIBRARY_PATH=/repertoire/contenant/les/librairies && /ton/executable/gs
Il utilisera alors les librairies présentes dans le LD_LIBRARY_PATH
Cordialement, M.
