Discussion :

[Jipété]

Bonsoir, c'est encore moi avec mes misères et mes codes maraboutés...

J'utilise un script Bash qui fait un tas de vérif's et de paramétrage de variables, puis va compiler mon .c ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
gcc "${infile}" -o "${outfile}" \
	`pkg-config --cflags --libs fuse` \
	-I"${incdir}" \
	-Wl,-rpath,"${INSTALL_DIR}" \
	-l:"${INSTALL_DIR}"/VBoxDDU.so \
	-Wall ${CFLAGS}

J'ai bien vérifié l'avant-dernière ligne avec echo "${INSTALL_DIR}" # ok : /usr/lib/virtualbox puis en ligne de commande un petit locate VBoxDDU.so me retourne un parfaitement correct /usr/lib/virtualbox/VBoxDDU.so et si je précise tout ça avec les détails c'est parce qu'à la fin de l'exécution du script, je me prends dans les dents un méchant /usr/bin/ld: ne peut trouver -l:/usr/lib/virtualbox/VBoxDDU.so qui me laisse KO !

Merci pour les pistes, car là, je n'ai pas la moindre idée de ce qu'il faut chercher et où, et j'ai juste l'impression que le message d'erreur n'est pas en rapport avec ce qui se passe dans la vraie vie.

[WhiteCrow]

Bonjour,
ça dépend de ton linker … mais en général avec une option -l:fichier on ne donne que le nom du fichier pas le path intégral (de souvenir à vérifier cependant). Le : signifie surtout de ne pas préfixer ou suffixer le nom donné.
Les chemins de recherche sont donnés au linker via l'option -L. Et c'est toujours bien d'utiliser un builder (même make …) qu'un script shell …

[Jipété]

Bonjour,
ça dépend de ton linker … mais en général avec une option -l:fichier on ne donne que le nom du fichier pas le path intégral (de souvenir à vérifier cependant). Le : signifie surtout de ne pas préfixer ou suffixer le nom donné.

alors, la compilation réglée comme ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#	-l:"${INSTALL_DIR}"/VBoxDDU.so \
	-l:VBoxDDU.so \

donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
/usr/bin/ld*: /tmp/ccFSttCY.o*: dans la fonction «*main*»*:
v64.c:(.text+0x4f1)*: référence indéfinie vers «*VDCreate*»
/usr/bin/ld*: v64.c:(.text+0x55e)*: référence indéfinie vers «*VDOpen*»
/usr/bin/ld*: v64.c:(.text+0x5fb)*: référence indéfinie vers «*VDOpen*»
/usr/bin/ld*: /tmp/ccFSttCY.o*: dans la fonction «*initialisePartitionTable*»*:
v64.c:(.text+0xace)*: référence indéfinie vers «*VDGetSize*»
/usr/bin/ld*: v64.c:(.text+0xb16)*: référence indéfinie vers «*VDRead*»
/usr/bin/ld*: v64.c:(.text+0xd11)*: référence indéfinie vers «*VDRead*»
/usr/bin/ld*: /tmp/ccFSttCY.o*: dans la fonction «*VD_destroy*»*:
v64.c:(.text+0x10e6)*: référence indéfinie vers «*VDCloseAll*»
/usr/bin/ld*: /tmp/ccFSttCY.o*: dans la fonction «*VD_flush*»*:
v64.c:(.text+0x1120)*: référence indéfinie vers «*VDFlush*»
/usr/bin/ld*: /tmp/ccFSttCY.o*: dans la fonction «*VD_read*»*:
v64.c:(.text+0x1538)*: référence indéfinie vers «*VDRead*»
/usr/bin/ld*: /tmp/ccFSttCY.o*: dans la fonction «*VD_write*»*:
v64.c:(.text+0x1780)*: référence indéfinie vers «*VDWrite*»
collect2: error: ld returned 1 exit status
vdbuild_new: 60: -l:VBoxDDU.so: not found

et comme ça (retour à l'original)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	-l:"${INSTALL_DIR}"/VBoxDDU.so \
#	-l:VBoxDDU.so \

donne juste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
/usr/bin/ld*: ne peut trouver -l:/usr/lib/virtualbox/VBoxDDU.so
collect2: error: ld returned 1 exit status
vdbuild_new: 61: -Wall: not found

Les chemins de recherche sont donnés au linker via l'option -L.

J'ai essayé avec -L, c'est toujours une catastrophe, et avec -l, vu que le résultat change en fonction de comment je commente/décommente les deux lignes, on en conclut que cette option est bien prise en compte et que la blagounette est ailleurs, mais où ?

Et c'est toujours bien d'utiliser un builder (même make …) qu'un script shell …

Oui, mais comme je ne suis pas capable d'écrire un Makefile (malgré ton aide et toutes les aides du monde), et que le script est beaucoup plus lisible donc compréhensible (pour moi), je vais rester dans cette voie.

[Bousk]

Est-ce que c'est pas une connerie du genre utilisateur ? La lib est installée pour un autre que celui qui exécute le script de build ?
Je me prends parfois les pieds avec ça sous Unix...

[WhiteCrow]

tu as bien essayé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
...
-L "${variable contenant le nom du répertoire où se trouve VBoxDDU.so sans espaces qui traînent …}"   -l:VBoxDDU.so \
...

-L pour ajouter un chemin à la liste des chemins cherchés et -l: pour spécifier un nom brut de bibliothèque ?

Sinon, quitte à faire quick and dirty, donne directement la bibliothèque en paramètre (avec tout son chemin sans option préalable).

[Jipété]

tu as bien essayé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
...
-L "${variable contenant le nom du répertoire où se trouve VBoxDDU.so sans espaces qui traînent …}"   -l:VBoxDDU.so \
...

-L pour ajouter un chemin à la liste des chemins cherchés et -l: pour spécifier un nom brut de bibliothèque ?

Sinon, quitte à faire quick and dirty, donne directement la bibliothèque en paramètre (avec tout son chemin sans option préalable).

J'ai fait comme ça : -L:"${INSTALL_DIR}"-l:VBoxDDU.so \ et comme ça -L:"${INSTALL_DIR}" -l:VBoxDDU.so \ et c'est toujours pareil, l'avalanche de "référence indéfinie"...
tout comme avec -l:/usr/lib/virtualbox/VBoxDDU.so \ ou avec -L:...

C'est épuisant...

[Jipété]

Est-ce que c'est pas une connerie du genre utilisateur ? La lib est installée pour un autre que celui qui exécute le script de build ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ls -l /usr/lib/virtualbox/VBoxDDU.so
-rw-r--r-- 1 root root 439064 13 janv. 20:41 /usr/lib/virtualbox/VBoxDDU.so

et comme c'est le genre de boulot que je fais en root, ça devrait le faire...

J'ai même tenté un chmod 755 du fichier, le résultat est identique.

(merci pour le ménage)

[Jipété]

J'ai une piste :

Trouvé sur un site une option pour vérifier le contenu d'une librairie avec nm fichier, donc je teste, et bim !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ nm /usr/lib/virtualbox/VBoxDDU.so 
nm: /usr/lib/virtualbox/VBoxDDU.so: aucun symbole

Ça ne serait pas plutôt ça, mon problème ?

Maintenant, pourquoi une librairie fournie par Oracle ne contiendrait aucun symbole, ça me dépasse complètement...

Ou alors c'est encore une mauvaise traduc' ? :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ nm -D /usr/lib/virtualbox/VBoxDDU.so | wc -l
325

325 lignes de symboles divers dont je retrouve certains noms dans le .c que j'essaie de compiler...
L'option -D = --dynamic Afficher les symboles dynamiques au lieu des symboles normaux.

Mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ nm -g /usr/lib/virtualbox/VBoxDDU.so | wc -l
nm: /usr/lib/virtualbox/VBoxDDU.so: aucun symbole
0

L'option -g concerne les symboles externes.

[Jipété]

Bon, man gcc c'est juste totalement illisible et imbuvable, man ld c'est un peu mieux et maintenant je me bats avec ce comportement bizarre (que j'ai déjà signalé et) que personne n'a relevé :
avec cette config

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#	-l :"${INSTALL_DIR}"/VBoxDDU.so \
	-l :/usr/lib/virtualbox/VBoxDDU.so \

j'ai une avalanche d'erreurs "référence indéfinie" plus le fichier non trouvé,
avec cette config

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	-l :"${INSTALL_DIR}"/VBoxDDU.so \
#	-l :/usr/lib/virtualbox/VBoxDDU.so \

je n'ai que le fichier non trouvé, et si je fais afficher "${INSTALL_DIR}"/VBoxDDU.so, ça ressemble en tous points à /usr/lib/virtualbox/VBoxDDU.so.

Il n'y a aucune différence dans les strings et pourtant le comportement est différent.
Qui peut m'expliquer ça ?

Un petit bout du man ld pour expliquer l'espace avant ":" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
       -l namespec
       --library=namespec
           Add the archive or object file specified by namespec to the list of files to link. This option may be
           used any number of times. If namespec is of the form :filename, ld will search the library path for a
           file called filename

J'ai cependant remarqué que dans la forme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

	-l :/usr/lib/virtualbox/VBoxDDU.so \

, j'ai un message d'erreur supplémentaire, difficile à repérer après l'avalanche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
...
v64.c:(.text+0x1780)*: référence indéfinie vers «*VDWrite*»
collect2: error: ld returned 1 exit status
vdbuild_new: 63: -l: not found

Le -l<espace> ne semble pas être apprécié, malgré l'aide qui le montre... D'ailleurs,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
-l: /... --> "-l" not found
-l:/... --> /... not found

[Jipété]

Allez, on se calme, et on reprend doucement, sur une seule ligne et en virant les trucs que je ne capte pas, ça donne ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gcc "${infile}" -o "${outfile}" $(pkg-config --cflags --libs fuse) -I"${incdir}" -l"${INSTALL_DIR}"/VBoxDDU.so -Wall ${CFLAGS}

Je rappelle que c'est dans un script à qui je passe infile, outfile et incdir, qui sont testés au début, donc je le fais exécuter, et paf !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
/usr/bin/ld : ne peut trouver -l/usr/lib/virtualbox/VBoxDDU.so
collect2: error: ld returned 1 exit status

Pour vérifier que je ne suis pas fou,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ file /usr/lib/virtualbox/VBoxDDU.so 
/usr/lib/virtualbox/VBoxDDU.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=23e07844434341c2508bd99bfa4150fa1b96573a, stripped

Donc le fichier est bien à la bonne place et au bon nom.
Je ne vois pas en quoi ni comment un make pourrait faire mieux qu'un "one_line" limpide.

D'autant plus qu'en suivant un tuto trouvé là, j'arrive avec les options gcc -E puis -S et enfin -c à avoir un fichier binaire, hé ouais.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ file v64
v64: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), stripped

Ensuite je le linke avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ld -o test /usr/lib/virtualbox/VBoxDDU.so v64 -lc
ld: erreur dans v64(.eh_frame); aucune table .eh_frame_hdr ne sera créée
ld : avertissement : le symbole d'entrée _start est introuvable ; utilise par défaut 0000000000401000

et là ld est capable de trouver ce fameux .so, c'est dingue -- malheureusement, je n'ai pas réussi à décoder l'option -lc, exemple trouvé là.
Mais il n'est pas exécutable, ou plutôt, ça se vautre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ file test 
test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, not stripped
$ ./test -h
bash: ./test: Aucun fichier ou dossier de ce type

C'est faux, dessus, je sais que l'option -h est valide/valable.


Et j'en suis là, et je vois bien que je n'avancerai pas plus loin, car je viens de faire le test suivant :
dans un dossier créé à la racine du système de fichiers dans lequel j'ai recopié le .c et les .h dans des sous-dossiers, je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ gcc v64.c -o test64 $(pkg-config --cflags --libs fuse) -I./include/ -l/usr/src/virtualbox/VBoxDDU.so
/usr/bin/ld : ne peut trouver -l/usr/src/virtualbox/VBoxDDU.so
collect2: error: ld returned 1 exit status

Ça dépasse mon entendement...

[Bousk]

T'es sûr que tu dois utiliser le .so et pas un .a ou autre ?
Aussi, la lib à lier doit avoir été compilée avec le même compilo et les mêmes options pour être compatible.

[Jipété]

T'es sûr que tu dois utiliser le .so et pas un .a ou autre ?

Ben y a pas de .a

Aussi, la lib à lier doit avoir été compilée avec le même compilo et les mêmes options pour être compatible.

T'es sûr de toi, là ? Tu m'achèves...

Allez, toute l'histoire :
ça remonte au bon vieux temps des machines et des OS 32-bits, et c'est un outil qui permettait de "monter" des disques virtuels (.vdi de VirtualBox-Oracle et .vhd de Microsoft [me souvient plus du nom du prog]) pour y accéder en dehors de la machine virtuelle, genre tu fais une boulette dans la mv et elle ne reboote plus, tu montes le disque tout seul avec l'outil, tu corriges, tu démontes et la mv repart comme s'il ne s'était rien passé.
On trouvait facilement le .c sur le web, il était simple à compiler et a fait mon bonheur pendant des années.

Ce que je suis en train d'envisager, c'est de compiler le même code dans une machine 64 bits, puisque les temps ont changé. Le problème, c'est que VirtualBox aussi a changé, et que plutôt que faire évoluer cet outil, ils en ont créé deux autres, qui me semblent moins agréables à l'usage, d'où mon envie d'arriver à quelque chose avec ce code.

Je ne dois pas en être bien loin, regarde :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
$ gcc v64.c -E -o test64.e $(pkg-config --cflags --libs fuse) -I./include/
$ gcc v64.c -S -o test64.s $(pkg-config --cflags --libs fuse) -I./include/
$ gcc v64.c -c -o test64.o $(pkg-config --cflags --libs fuse) -I./include/
$ lsd
Tri par date, le plus récent tout en haut :
total 440
-rw-r--r-- 1  22416 11 mars  16:35 test64.o
-rw-r--r-- 1  37859 11 mars  16:34 test64.s
-rw-r--r-- 1 349127 11 mars  16:33 test64.e
drwxr-xr-x 5   4096 11 mars  15:51 include/
-rw-r--r-- 1  26847 11 mars  15:51 v64.c

Mais après ça se complique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ ld -o test64 /usr/lib/virtualbox/VBoxDDU.so test64.o -lc
ld : avertissement : le symbole d'entrée _start est introuvable ; utilise par défaut 0000000000401200
ld : test64.o : dans la fonction « main » :
v64.c:(.text+0x655) : référence indéfinie vers « fuse_opt_add_arg »
ld : v64.c:(.text+0x6f0) : référence indéfinie vers « fuse_opt_add_arg »
ld : v64.c:(.text+0x706) : référence indéfinie vers « fuse_opt_add_arg »
ld : v64.c:(.text+0x719) : référence indéfinie vers « fuse_opt_add_arg »
ld : v64.c:(.text+0x742) : référence indéfinie vers « fuse_opt_add_arg »
ld : test64.o:v64.c:(.text+0x75b) : encore plus de références indéfinies suivent vers « fuse_opt_add_arg »
ld : test64.o : dans la fonction « main » :
v64.c:(.text+0x7ad) : référence indéfinie vers « fuse_main_real »
$
$ ld -o test64 /usr/lib/virtualbox/VBoxDDU.so test64.o
ld: test64.o: référence au symbole non défini « fflush@@GLIBC_2.2.5 »
ld : /lib/x86_64-linux-gnu/libc.so.6 : erreur lors de l'ajout de symboles : DSO manquant dans la ligne de commande

C'est quoi ça, DSO ?

[Sve@r]

Bonjour

Et j'en suis là, et je vois bien que je n'avancerai pas plus loin, car je viens de faire le test suivant :
dans un dossier créé à la racine du système de fichiers dans lequel j'ai recopié le .c et les .h dans des sous-dossiers, je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ gcc v64.c -o test64 $(pkg-config --cflags --libs fuse) -I./include/ -l/usr/src/virtualbox/VBoxDDU.so
/usr/bin/ld : ne peut trouver -l/usr/src/virtualbox/VBoxDDU.so
collect2: error: ld returned 1 exit status

Ça dépasse mon entendement...

Juste pour info, l'option "-l" de gcc (de ld en fait) est là pour générer un raccourci. Exemple "-lm" est un raccourci de "libm.so". Pour résumer "-ltruc" devient "libtruc.so"
Ainsi la commande gcc -lm truc.c -o truc est traduite en gcc /usr/lib/libm.so truc.c -o truc (enfin le chemin "/usr/lib" dépend de ton architecture).

Tu n'es pas obligé d'utiliser ce raccourci "-l". Tu peux très bien lier une librairie X pour laquelle soit tu ne veux pas utiliser le raccourci "-l", soit il n'y a pas de raccourci "-l". Dans ce cas, tu lui mets simplement son nom, sans option.
Dans ton cas, ça devrait être gcc v64.c $(pkg-config --cflags --libs fuse) -I./include/ /usr/src/virtualbox/VBoxDDU.so -o test64 (enfin moi j'aime bien mettre "-o" en dernier mais ce n'est pas obligatoire).

[Jipété]

Dans ton cas, ça devrait être gcc v64.c $(pkg-config --cflags --libs fuse) -I./include/ /usr/src/virtualbox/VBoxDDU.so -o test64.

Presque (tu m'as fait une peur...), c'est juste une étourderie, rien de grave -->

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ gcc v64.c $(pkg-config --cflags --libs fuse) -I./include/ /usr/lib/virtualbox/VBoxDDU.so -o test64
$ ls -l | grep test64
-rwxr-xr-x 1 root root  24176 11 mars  17:38 test64

On est bons, on est bons !

Le problème c'est après :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ./test64 -h
./test64: error while loading shared libraries: VBoxDDU.so: cannot open shared object file: No such file or directory

Je dois être maudit...

Ou j'ai un problème de chemin pas défini, mais je ne me souviens pas dans quelle variable ça se cache,

[Sve@r]

$ ls -l | grep test64

ls -l test64

Le problème c'est après :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ./test64 -h
./test64: error while loading shared libraries: VBoxDDU.so: cannot open shared object file: No such file or directory

Je dois être maudit...

C'est un message qui arrive en général quand la librairie dynamique disparait après compilation. Vérifie juste pour la forme ls -lL /usr/lib/virtualbox/VBoxDDU.so...? (ok je vois que tu l'as fait dans un post précédent mais bon, je ne vois que ça)...

ça remonte au bon vieux temps des machines et des OS 32-bits, et c'est un outil qui permettait de "monter" des disques virtuels (.vdi de VirtualBox-Oracle et .vhd de Microsoft [me souvient plus du nom du prog]) pour y accéder en dehors de la machine virtuelle, genre tu fais une boulette dans la mv et elle ne reboote plus, tu montes le disque tout seul avec l'outil, tu corriges, tu démontes et la mv repart comme s'il ne s'était rien passé.
On trouvait facilement le .c sur le web, il était simple à compiler et a fait mon bonheur pendant des années.

Ce que je suis en train d'envisager, c'est de compiler le même code dans une machine 64 bits, puisque les temps ont changé. Le problème, c'est que VirtualBox aussi a changé, et que plutôt que faire évoluer cet outil, ils en ont créé deux autres, qui me semblent moins agréables à l'usage, d'où mon envie d'arriver à quelque chose avec ce code.

Mouais. Moi, quand une de mes machines ne démarre plus cause vdi foiré (sous-entendu "le VDI fonctionne mais l'OS qu'il contient a eu une merde"), je monte le VDI en tant que client dans une autre machine virtuelle (une minimaliste, qui ne contient qu'un Linux Live comme Slax que j'aime beaucoup) et j'y accède depuis l'OS de la seconde MV...

Et pour éviter certains soucis, mes machines virtuelles importantes (celles que je ne veux pas toucher) ont deux disques VDI

• un disque pour le système, immuable
• un disque pour les datas, normal

Comme ça, mon OS est toujours propre.

[Jipété]

J'ai été bien embêté, là, mais je m'en suis sorti :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
man ldconfig
Note  that ldconfig will only look at files that are named lib*.so* (for regular shared objects)

Alors j'ai créé un lien libvboxddu.so pointant vers VBoxDDU.so, j'ai recompilé et ça n'est toujours pas pris en compte, mais c'est parce que je suis trop pressé alors j'en oublie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
$ gcc v64.c $(pkg-config --cflags --libs fuse) -I./include/ /usr/lib/virtualbox/libvboxddu.so -o test64
$ ldd test64
	linux-vdso.so.1 (0x00007ffc0e395000)
	libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f970dc9d000)
	VBoxDDU.so => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f970dc7b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f970dab6000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f970dab0000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f970dd00000)
$ ldconfig
$ ldd test64
	linux-vdso.so.1 (0x00007ffec554b000)
	libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007fd4f6bb8000)
	VBoxDDU.so => /usr/lib/virtualbox/VBoxDDU.so (0x00007fd4f6b4c000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd4f6b2a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd4f6965000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd4f695f000)
	VBoxRT.so => /usr/lib/virtualbox/VBoxRT.so (0x00007fd4f660c000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fd4f643d000)
...
$ ./test64 -h
DESCRIPTION: This Fuse module uses the VirtualBox access library to open
a VirtualBox supported VD image-file and mount it as a Fuse file system.
The mountpoint contains a flat directory containing the files EntireDisk,
Partition1 .. PartitionN. These can then be loop mounted to access the
underlying file systems.
Version: 0.84
 
USAGE: ./test64 [options] -f image-file mountpoint
	-h	help
	-r	readonly
	-t	specify type (VDI, VMDK, VHD, or raw; default: auto)
	-f	VDimage-file
	-s	Snapshot file(s) to load on top of the image-file
	-a	allow all users to read disk
	-w	allow all users to read and write to disk
	-g	run in foreground
	-v	verbose
	-d	debug
	-l	list partitions and their size and type found in the image-file
 
NOTE: you must add the line "user_allow_other" (without quotes)
to /etc/fuse.conf and set proper permissions on /etc/fuse.conf
for this to work.

OUFFFFFFFFFFFFFFFFFFF !

Merci à tous, on va pouvoir passer un bon week-end,