Je crois, mais je peux me tromper, que tu n'as pas très bien compris le principe du bytecode.
Ce bytecode est très proche du binaire, juste un niveau au dessus, pour être portable. Voici comment se déroule la création d'un paquet :
* Compilation de chaque fichier .c ou .cpp dans un fichier .ll
* Compilation de chaque fichier .ll en un fichier .bc
Si on devait s'arrêter ici, on aurait effectivement plein de redondance, mais ce n'est pas ce qui est fait :
* Utilisation de llvm-link pour lier tous les fichiers .bc en un seul gros fichier .bc
Voilà, c'est là que tout s'est joué. Le bytecode est comme de l'assembleur : les bibliothèques ne sont pas inclues, on ne perd pas de place. On a juste des "call glib_machin_truc" ou "call machin::truc", mais sans rien d'autres.
Une fois le paquet récupérer, c'est là que la liaison est faite :) . C'est à ce moment qu'on dit «glib_machin_truc est un appel vers la fonction blabla dans la lib machin», donc c'est lié dynamiquement.
Par exemple, voici le Makefile utilisé pour compiler Cream :
all: $(SOURCES)
llvm-ld -o all -s $(SOURCES)
# Ici on met dans un paquet, les lignes suivantes sont côté client.
llc -o all.s all.bc
clang -o $(BINARY) all.s $(LIBS)
On voit qu'il y a des données qui sont perdues entre la somme des tailles des fichiers .b, et la taille du .bc. Ce sont les répétitions qui sont éliminées.
[^] # Re: Dépendances?
Posté par steckdenis . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 6.
Ce bytecode est très proche du binaire, juste un niveau au dessus, pour être portable. Voici comment se déroule la création d'un paquet :
* Compilation de chaque fichier .c ou .cpp dans un fichier .ll
* Compilation de chaque fichier .ll en un fichier .bc
Si on devait s'arrêter ici, on aurait effectivement plein de redondance, mais ce n'est pas ce qui est fait :
* Utilisation de llvm-link pour lier tous les fichiers .bc en un seul gros fichier .bc
Voilà, c'est là que tout s'est joué. Le bytecode est comme de l'assembleur : les bibliothèques ne sont pas inclues, on ne perd pas de place. On a juste des "call glib_machin_truc" ou "call machin::truc", mais sans rien d'autres.
Une fois le paquet récupérer, c'est là que la liaison est faite :) . C'est à ce moment qu'on dit «glib_machin_truc est un appel vers la fonction blabla dans la lib machin», donc c'est lié dynamiquement.
Par exemple, voici le Makefile utilisé pour compiler Cream :
SOURCES=main.b bookmarks.b callbacks.b command.b CreamView.b download.b favicon.b ftplib.b history.b ini.b keybindings.b
BINARY=cream
LIBS=-lwebkit-1.0 -lgtk-x11-2.0
INCLUDES=-I/usr/include/gtk-2.0 -I/usr/include/webkit-1.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/libsoup-2.4 -I. -I.. -DPREFIX=\"/usr/local\" -DLOCALEDIR=\"/usr/local/share/locale\" -D_REENTRANT
all: $(SOURCES)
llvm-ld -o all -s $(SOURCES)
# Ici on met dans un paquet, les lignes suivantes sont côté client.
llc -o all.s all.bc
clang -o $(BINARY) all.s $(LIBS)
%.b:%.c
clang-cc $*.c $(INCLUDES) -emit-llvm -o - | llvm-as | opt -std-compile-opts > $*.b
clean:
rm -f *.b
distclean: clean
rm -f all.* $(BINARY)
Et quand je liste le contenu du dossier, on voit ceci :
63564 sep 1 14:36 all.bc
10772 sep 1 14:35 bookmarks.b
19560 sep 1 14:35 callbacks.b
10484 sep 1 14:35 command.b
23392 sep 1 14:35 CreamView.b
5824 sep 1 14:35 download.b
3432 sep 1 14:35 favicon.b
23176 sep 1 14:35 ftplib.b
10256 sep 1 14:35 history.b
5808 sep 1 14:36 ini.b
7524 sep 1 14:36 keybindings.b
17804 sep 1 14:35 main.b
On voit qu'il y a des données qui sont perdues entre la somme des tailles des fichiers .b, et la taille du .bc. Ce sont les répétitions qui sont éliminées.