Utiliser des binaires sur un Mutualisé (pdftotext)

Bonjour,

si le binaire dépend de bibliothèque(s) tiers (non inclus dans le binaire, ce qui semble être le cas), alors non cela ne peut pas fonctionner vu qu'il y a de forte chance que ces bibliothèque ne soit pas présente sur un mutu.

Cordialement, janus57

Merci pour la réponse.

Mais du coup comment savoir si il y a des dépendances ?

J'avais pensé à ça, du coup en local, j'ai désinstaller propper-utils, et mon binaire que j'ai mis dans mon arbo fonctionne bien seul (a priori..; en espérant qu'il utilise pas d'autres choses).

Selon moi, le problème n'est pas vraiment un soucis de dépendance, mais plutôt de reconnaissance du fichier comme étant un binaire utilisable sur le mutu. Je ne sais pas si je suis clair.

https://packages.debian.org/fr/stretch/poppler-utils

> le binaire via ssh, ça ne marche pas, on me dit que le fichier ou le répertoire n'existe pas

la commande et le résultat exact auraient été indicatif

Bonjour,

j'ai désinstaller propper-utils

comment et sous quel OS, car cela ne désinstalle pas forcément les dépendances (et à prouver c'est relativement simple, il suffit de déposer le binaire sur un système vierge "out of the box").

Si vous pouvez upload le binaire + donner la commande précise que vous avez utilisé je pourrais tester sur un Debian.

Aussi faite attention à votre binaire selon que ce soit un 32 ou 64bits, car les mutu sont de mémoire en 32bits (donc un binaire 64bits ne passera jamais).

Cordialement, janus57

eh bien quand je suis dans le répertoire où se trouve le binaire, j'essaye de le lancer.

ex: (en étant à la racine, là où je vois le dossier www; pour info, j'ai créé le dossier cgi-bin ici)
cgi-bin/pdftotext --help

et le résultat c'est :
-ovh_ssh: cgi-bin/pdftotext: No such file or directory

Je m'y prend peut-être mal...

Voilà le binaire (j'ai mis dans un .zip) : https://we.tl/t-cXgLLjCNCO

Bon, pour la commande en ssh, je viens de me rendre compte que je ne sais pas l'éxécuter... (j'ai la même erreur sur l'environnement où ça marche (un docker pas forcément très propre non plus)).
Voilà comment j'arrive à faire marche le binaire via php :
passthru('/home/userovh/cgi-bin/pdftotext -enc UTF-8 -nopgbrk "/home/userovh/www/test.pdf" "/home/userovh/www/tmpPdfTxt"', $exit_code);

Et là dans mon fichier tmpPdfTxt, j'ai le texte qui est intégré.

Edit: ah oui, du coup je ne sais pas pour cette histoire de 32/64bits.
Moi je suis en 64bits. Mais où pourrais-je trouver le binaire en 32 pour tester ?

Bonjour,

Moi je suis en 64bits. Mais où pourrais-je trouver le binaire en 32 pour tester ?

sur une distribution en 32bits ? ou le site officiel (j'ai pas vérifié si il y en a un) ?

Cordialement, janus57

```text mais si 64bits, de nos jours...
```text
uname -a
Linux ssh02.cluster026.gra.hosting.ovh.net 4.14.61-ovh-vps-grsec-zfs-classid #1 SMP Tue Aug 7 02:27:59 CEST 2018 x86_64 GNU/Linux
```

rend l'exécutable, exécutable
```
chmod +x cgi/pdftotext
```

tu verras alors s'il manque des dépendances (en ssh) ```

```text Alors, je pense avoir récupérer le fichier 32bits ici : https://packages.debian.org/fr/stretch/i386/poppler-utils/download (j'ai extrait le .deb, jusqu'à trouver mon pdftotext)

Du coup, avec ce fichier sur l'hébergement, je me retrouve avec un exit_code = 11

Mais comme l'a souligné @kyodev, un uname -a me montre que je suis sur un 64bits a priori (sur le mutu). ```

pas de 32 bits, je doute que les mutus soit en multiarch
tu a rendu le fichier exécutable?
`./executable` ça répond quoi, en ssh?

```text Oui, je l'ai rendu exécutable. Voici le résultat.
Plusieurs essais :
le fichier pdftotext (issu du package i386) = Segmentation fault
le fichier pdftotext que j'avais au départ = No such file or directory
j'ai pris dans le doute le fichier package amd64 (https://packages.debian.org/fr/stretch/amd64/poppler-utils/download), et le résultat = No such file or directory ```

Bonjour,

historiquement les container de OVH était en 32bits y a pas si longtemps que ça, donc visiblement il sont passé en 64bits (enfin une bonne nouvelle).

Sinon je vous conseille de prendre le binaire de jessie (si cela n'a pas changé les mutu sont basé sur des container Jessie).

Cordialement, janus57

moi je suis en stable donc, stretch

```shell
cd repertoireCgi
./executable
```
No such file or directory indique que tu ne l'appelles pas correctement, car par défaut la recherche se fait dans le PATH

quelle commande **exacte** utilises tu?

Merci pour l'astuce (de prendre jessie au lieu de stretch), je pense que ça peut avoir un impact.

En revanche, j'ai fait le test, et un cgi-bin/pdftotext = No such file or directory (avec la version du package amd64)
Je ne comprend pas... et quand j'utilise celui de la version du package i386, ça me sors "Segmentation fault".

eh bien en étant dans le répertoire cgi-bin, je fais : ./pdftotext

si c'est le fichier pdftotext du package i386, ça m'affiche Segmentation fault
si c'est le fichier pdftotext du package amd64, ça m'affiche No such file or directory

alors je comprends plus, ça doit concerner des dépendances non statisfaites, ce qui n'est pas surprenant vu les requis de packages debian

il n'existe pas de classe php pdf2txt?

edit:
trop compliqué pour moi :/
```
dpkg --print-architecture
i386
uname -m
x86_64
```

J'ai fait un essai avec le package arm64 (je me suis dit tant qu'à faire...), et en éxécutant cgi-bin/pdftotext, j'ai :
-ovh_ssh: cgi-bin/pdftotext: cannot execute binary file: Exec format error

Eh bien, non pas vraiment...
Je galère depuis un moment avec ça.

edit:
Ah ! avec ta commande (dpkg --print-architecture), on sait au moins que je suis en i386.
on avance.

Malheureusement, je dois absolument partir, j'espère que je trouverais une solution.
Finalement, là je suis donc à mon "Segmentation fault" (exécuté en ssh) et exitcode = 11 (exécuté via passthru en php).
Si d'autres personnes ont des idées sur les solutions avec ces deux erreurs. Je suis preneur.

Merci beaucoup en tout cas, et au plaisir de pouvoir continuer à échanger avec vous lorsque je serais de nouveau dispo. ;)

arm64, sur des dédiés arm peut-être
oui et non
l'architecture des paquets est 386
mais le kernel en amd64
après, sur les containers je ne peux aller plus loin

```text

En revanche, j'ai fait le test, et un cgi-bin/pdftotext = No such file or directory (avec la version du package amd64)

oui donc c'est un problème de dépendances.
J'ai testé de mon côté et j'ai fait ça :

$ mkdir ovhtest
$ cd ovhtest

* On télécharge le paquet poppler-utils, on l'extrait pour récupérer pdftotext

$ apt-get download poppler-utils
Réception de : 1 http://deb.debian.org/debian/ jessie/main poppler-utils amd64 0.26.5-2+deb8u4 [141 kB]
141 ko réceptionnés en 0s (185 ko/s)
$ mkdir poppler-utils
$ dpkg -x poppler-utils_0.26.5-2+deb8u4_amd64.deb poppler-utils/
$ mv poppler-utils/usr/bin/pdftotext ./

* On l'exécute

$ chmod +x pdftotext
$ ./pdftotext
./pdftotext: error while loading shared libraries: libpoppler.so.46: cannot open shared object file: No such file or directory

* On télécharge la dépendance

$ apt-get download libpoppler46
Réception de : 1 http://deb.debian.org/debian/ jessie/main libpoppler46 amd64 0.26.5-2+deb8u4 [1 211 kB]
1 211 ko réceptionnés en 0s (1 761 ko/s)
$ mkdir libpoppler46
$ dpkg -x libpoppler46_0.26.5-2+deb8u4_amd64.deb libpoppler46/

* On créé un dossier pour stocker les librairies

$ mkdir lib
$ mv libpoppler46/usr/lib/x86_64-linux-gnu/* lib/

* On relance pdftotext en lui indiquant le path des librairies

$ env LD_LIBRARY_PATH="lib" ./pdftotext
./pdftotext: error while loading shared libraries: libopenjpeg.so.5: cannot open shared object file: No such file or directory

* On fait la même chose pour cette librairie

$ apt-get download libopenjpeg5
Réception de : 1 http://deb.debian.org/debian/ jessie/main libopenjpeg5 amd64 1:1.5.2-3 [111 kB]
111 ko réceptionnés en 0s (148 ko/s)
$ mkdir libopenjpeg5
$ dpkg -x libopenjpeg5_1%3a1.5.2-3_amd64.deb libopenjpeg5/
$ mv libopenjpeg5/usr/lib/x86_64-linux-gnu/* lib/

* on relance pdftotext

$ env LD_LIBRARY_PATH="lib" ./pdftotext
pdftotext version 0.26.5
Copyright 2005-2014 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
Usage: pdftotext [options] []
-f : first page to convert
-l : last page to convert
-r : resolution, in DPI (default is 72)
{...]

* On supprime ce qui n'est plus utile

$ rm *.deb
$ rm -R libpoppler46 libopenjpeg5 poppler-utils

en espérant que ça pourra t'aider.

Cordialement,
Boris. ```

Après tu peux renormmer pdftotext en pdftotext.bin

et créer un fichier "pdftotext" contenant :

#!/bin/bash
tmp=$(dirname $0)
path=$(realpath $tmp)

export LD_LIBRARY_PATH="$path/lib"

$path/pdftotext.bin $@

ne pas oublier de faire un
`chmod +x pdftotext`

Cordialement,
Boris.

on peut faire ça sur un mutu?
```
apt-get download poppler-utils
E: Archives directory /var/cache/apt/archives/partial is missing. - Acquire (13: Permission denied)

```

A ce moment là il faut télécharger les paquet directement sur internet.

On l'exécute
$ chmod +x pdftotext
$ ./pdftotext
./pdftotext: error while loading shared libraries: libpoppler.so.46: cannot open shared object file: No such file or directory

Salut BorisM pour ton aide et ton test détaillé.
J'ai essayé ce que tu as fait, mais j'ai un problème...
Chez moi, l'erreur lié au lancement de ./pdftotext ne s'affiche pas comme chez toi.
On me dit simplement :
-ovh_ssh: ./pdftotext: No such file or directory

Compliqué du coup de déduire ce qu'il manque comme toi.
J'ai quand même poursuivi le test, et du coup après avoir ajouté les librairies qui étaient manquantes chez toi, on a cette erreur :
-ovh_ssh: end: command not found
(le test a été fait à l'ajout de libpoppler46 et aussi à l'ajout de libopenjpeg5; les deux = même résultat)

Du coup, je ne peux pas aller plus loin pour tenter mon debug.
Est-ce qu'il y aurait quelque chose de particulier à faire pour pouvoir arriver à ce niveau d'affichage des erreurs ? (comme toi) ?
J'étais ravi de lire ta réponse, mais du coup à l'essai c'est moins concluant :(

PS: j'ai télécharger les librairies via mon ordi et je les ai envoyé via ftp.

Merci par avance.

pdftotext

Tu peux tenter un
`ldd pdftotext`
pour voir les dépendances.
et
`ldd -v pdftotext`
pour voir les dépendances des dépendances

à priori, en mutu, dans un hôte en 64b, le container est en 32b! donc si
```
$dpkg --print-architecture
i386
```
fais les manip en 32b. tu échapperas peut être au segfault

Bon, j'ai fait une petite erreur tout à l'heure.
Mon erreur `-ovh_ssh: end: command not found` était en fait lié à une erreur dans ma commande, j'avais tapé `end` au lieu de `env` -_-'
Mais finalement, ça ne corrige pas le soucis. Avec la bonne commande :
`$ env LD_LIBRARY_PATH="lib" ./pdftotext
env: ./pdftotext: No such file or directory`

`ldd pdftotext` ET `ldd -v pdftotext` = même résultat :
`not a dynamic executable`

(cela toujours avec mon dossier de test de tout à l'heure, sur des binaire amd64).

Maintenant, en prenant en compte la remarque de kyodev, la même chose avec les binaire i386:
`$ env LD_LIBRARY_PATH="lib" ./pdftotext
Segmentation fault`

et l'autre commande :
`$ ldd -v pdftotext
statically linked`

Version information:
/lib/security/hosting-securize.so:
libdl.so.2 (GLIBC_2.0) => /lib/i386-linux-gnu/libdl.so.2
libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
/lib/i386-linux-gnu/libdl.so.2:
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
libc.so.6 (GLIBC_PRIVATE) => /lib/i386-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.1) => /lib/i386-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
/lib/i386-linux-gnu/libc.so.6:
ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2

Vous voyez d'autres choses que je pourrais faire ?

essayer d'installer une version légèrement supérieure à 0.26.5-2? (quelques bugs résolus)
https://snapshot.debian.org/binary/poppler-utils/

(la version stable strech 0.48 ne passerait pas sur la version de libstdc++6 à priori)

J'ai essayé ça, avec plusieurs versions et rien de concluant.

Je vais devoir me tourner vers d'autres solutions (comme sortir du Mutu...), c'est dommage car je reste persuadé qu'on devrait pouvoir exécuter ce binaire.

La solution de BorisM me semble très pertinente, mais je n'arrive pas au même résultat que lui.

boris il est pas sur un mutu, du moins pas chez ovh

edit:
car sur un mutu ailleurs, j'arrive à reproduire sa méthode

humm ceci explique cela !