exe_statique : main.o blabla.o
g++ -o $@ $^ $(shell pkg-config --libs gtk+-2.0) -mwin32 -static
Et en mettant le -static avant le pkg_config ?
exe_statique : main.o blabla.o
g++ -o $@ $^ $(shell pkg-config --libs gtk+-2.0) -mwin32 -static
Et en mettant le -static avant le pkg_config ?
exe_statique : main.o blabla.o
g++ -o $@ $^ $(shell pkg-config --libs gtk+-2.0) -mwin32 -static
Et en mettant le -static avant le pkg_config ?
Le .la est un fichier texte qui est compris par libtool. Il contient
entre autre l'adresse de la bibliothèque .a et ses dépendances.
cat /usr/lib64/libgtk-x11-2.0.la
Comment appeler directement le linker (plutôt que g++) et lui demander
d'être bavard ?
Avec la commande ld, mais il ne faut pas se louper dans les modèles
de mémoire.
Normalement. Mais il ne faut pas oublier que la gestion des
bibliothèques est un truc particulièrement foireux sous Windows. Il
faudrait que tu regardes avec l'équivalent de nm si les symboles
soi-disant manquant sont dans l'exécutable ou non. Ce serait déjà un
bon début.
Le .la est un fichier texte qui est compris par libtool. Il contient
entre autre l'adresse de la bibliothèque .a et ses dépendances.
cat /usr/lib64/libgtk-x11-2.0.la
Comment appeler directement le linker (plutôt que g++) et lui demander
d'être bavard ?
Avec la commande ld, mais il ne faut pas se louper dans les modèles
de mémoire.
Normalement. Mais il ne faut pas oublier que la gestion des
bibliothèques est un truc particulièrement foireux sous Windows. Il
faudrait que tu regardes avec l'équivalent de nm si les symboles
soi-disant manquant sont dans l'exécutable ou non. Ce serait déjà un
bon début.
Le .la est un fichier texte qui est compris par libtool. Il contient
entre autre l'adresse de la bibliothèque .a et ses dépendances.
cat /usr/lib64/libgtk-x11-2.0.la
Comment appeler directement le linker (plutôt que g++) et lui demander
d'être bavard ?
Avec la commande ld, mais il ne faut pas se louper dans les modèles
de mémoire.
Normalement. Mais il ne faut pas oublier que la gestion des
bibliothèques est un truc particulièrement foireux sous Windows. Il
faudrait que tu regardes avec l'équivalent de nm si les symboles
soi-disant manquant sont dans l'exécutable ou non. Ce serait déjà un
bon début.
Les DLL de GTK+ doivent obligatoirement etre présentes si des fonctions de
ces DLL sont utilisées statiquement
(sous Windows, on n'a pas besoin de lib pour les
interfaces, totu est dans l'api)
mais si les DLL ne sont pas trop grosses ou trop nombreuses, on peut à
la rigueur les mettre en resources et les extraire au premier lancement.
Les DLL de GTK+ doivent obligatoirement etre présentes si des fonctions de
ces DLL sont utilisées statiquement
(sous Windows, on n'a pas besoin de lib pour les
interfaces, totu est dans l'api)
mais si les DLL ne sont pas trop grosses ou trop nombreuses, on peut à
la rigueur les mettre en resources et les extraire au premier lancement.
Les DLL de GTK+ doivent obligatoirement etre présentes si des fonctions de
ces DLL sont utilisées statiquement
(sous Windows, on n'a pas besoin de lib pour les
interfaces, totu est dans l'api)
mais si les DLL ne sont pas trop grosses ou trop nombreuses, on peut à
la rigueur les mettre en resources et les extraire au premier lancement.
Le 8 mars 2012, JKB a écrit :Le .la est un fichier texte qui est compris par libtool. Il contient
entre autre l'adresse de la bibliothèque .a et ses dépendances.
---cat /usr/lib64/libgtk-x11-2.0.la
(...)
# Names of this library.
library_names='libgtk-x11-2.0.so.0.1800.6 libgtk-x11-2.0.so.0
libgtk-x11-2.0.so'
# The name of the static archive.
old_library=''
(...)
---
Mauvais signe, non ?
Comment appeler directement le linker (plutôt que g++) et lui demander
d'être bavard ?
Avec la commande ld, mais il ne faut pas se louper dans les modèles
de mémoire.
C'est tout l'objet de mon « Comment » ;-)Normalement. Mais il ne faut pas oublier que la gestion des
bibliothèques est un truc particulièrement foireux sous Windows. Il
faudrait que tu regardes avec l'équivalent de nm si les symboles
soi-disant manquant sont dans l'exécutable ou non. Ce serait déjà un
bon début.
MinGW fournit nm. Qu'est-ce qu'un symbole ?
L'erreur que j'obtiens au lancement d'exe_statique est du style « Il est
impossible de trouver libtruc.dll. » sans plus de détails. Bien sûr
libtruc.dll est dans la ligne de compilation. Ah mais tiens, il faudrait
peut-être que je passe --static à pkg-config :-D J'essaierai ce soir.
Le 8 mars 2012, JKB a écrit :
Le .la est un fichier texte qui est compris par libtool. Il contient
entre autre l'adresse de la bibliothèque .a et ses dépendances.
---
cat /usr/lib64/libgtk-x11-2.0.la
(...)
# Names of this library.
library_names='libgtk-x11-2.0.so.0.1800.6 libgtk-x11-2.0.so.0
libgtk-x11-2.0.so'
# The name of the static archive.
old_library=''
(...)
---
Mauvais signe, non ?
Comment appeler directement le linker (plutôt que g++) et lui demander
d'être bavard ?
Avec la commande ld, mais il ne faut pas se louper dans les modèles
de mémoire.
C'est tout l'objet de mon « Comment » ;-)
Normalement. Mais il ne faut pas oublier que la gestion des
bibliothèques est un truc particulièrement foireux sous Windows. Il
faudrait que tu regardes avec l'équivalent de nm si les symboles
soi-disant manquant sont dans l'exécutable ou non. Ce serait déjà un
bon début.
MinGW fournit nm. Qu'est-ce qu'un symbole ?
L'erreur que j'obtiens au lancement d'exe_statique est du style « Il est
impossible de trouver libtruc.dll. » sans plus de détails. Bien sûr
libtruc.dll est dans la ligne de compilation. Ah mais tiens, il faudrait
peut-être que je passe --static à pkg-config :-D J'essaierai ce soir.
Le 8 mars 2012, JKB a écrit :Le .la est un fichier texte qui est compris par libtool. Il contient
entre autre l'adresse de la bibliothèque .a et ses dépendances.
---cat /usr/lib64/libgtk-x11-2.0.la
(...)
# Names of this library.
library_names='libgtk-x11-2.0.so.0.1800.6 libgtk-x11-2.0.so.0
libgtk-x11-2.0.so'
# The name of the static archive.
old_library=''
(...)
---
Mauvais signe, non ?
Comment appeler directement le linker (plutôt que g++) et lui demander
d'être bavard ?
Avec la commande ld, mais il ne faut pas se louper dans les modèles
de mémoire.
C'est tout l'objet de mon « Comment » ;-)Normalement. Mais il ne faut pas oublier que la gestion des
bibliothèques est un truc particulièrement foireux sous Windows. Il
faudrait que tu regardes avec l'équivalent de nm si les symboles
soi-disant manquant sont dans l'exécutable ou non. Ce serait déjà un
bon début.
MinGW fournit nm. Qu'est-ce qu'un symbole ?
L'erreur que j'obtiens au lancement d'exe_statique est du style « Il est
impossible de trouver libtruc.dll. » sans plus de détails. Bien sûr
libtruc.dll est dans la ligne de compilation. Ah mais tiens, il faudrait
peut-être que je passe --static à pkg-config :-D J'essaierai ce soir.
Je cross-poste sans FU2 car je ne sais pas quel est le groupe le plus
adapté
Je cross-poste sans FU2 car je ne sais pas quel est le groupe le plus
adapté
Je cross-poste sans FU2 car je ne sais pas quel est le groupe le plus
adapté
- peut-on produire un exécutable qui se suffise à lui-même, et avec
quelles options de compilation ?
- peut-on produire un exécutable qui se suffise à lui-même, et avec
quelles options de compilation ?
- peut-on produire un exécutable qui se suffise à lui-même, et avec
quelles options de compilation ?
Je cross-poste sans FU2 car je ne sais pas quel est le groupe le plus
adapté
Ce faisant, Lucas, tu te coupes de tous tes lecteurs potentiels passant
par des serveurs tels que ceux de Free, de GalacSys, de Neottia, et
sûrement un certain nombres d'autres. Sur ces serveurs, les articles
diapubliés sur au moins trois groupes n'apparaissent pas s'il n'y a
pas un suivi de positionné.
Je cross-poste sans FU2 car je ne sais pas quel est le groupe le plus
adapté
Ce faisant, Lucas, tu te coupes de tous tes lecteurs potentiels passant
par des serveurs tels que ceux de Free, de GalacSys, de Neottia, et
sûrement un certain nombres d'autres. Sur ces serveurs, les articles
diapubliés sur au moins trois groupes n'apparaissent pas s'il n'y a
pas un suivi de positionné.
Je cross-poste sans FU2 car je ne sais pas quel est le groupe le plus
adapté
Ce faisant, Lucas, tu te coupes de tous tes lecteurs potentiels passant
par des serveurs tels que ceux de Free, de GalacSys, de Neottia, et
sûrement un certain nombres d'autres. Sur ces serveurs, les articles
diapubliés sur au moins trois groupes n'apparaissent pas s'il n'y a
pas un suivi de positionné.
Je compile avec GCC (dans MinGW sous Windows). Je voudrais obtenir un
exécutable qui se suffise à lui-même,
Mais patatras : sous Win, si je tente de lancer l'exécutable
« statique » sur une machine n'ayant pas GTK+, j'obtiens une erreur « ne
trouve pas libmachin.dll »
Je compile avec GCC (dans MinGW sous Windows). Je voudrais obtenir un
exécutable qui se suffise à lui-même,
Mais patatras : sous Win, si je tente de lancer l'exécutable
« statique » sur une machine n'ayant pas GTK+, j'obtiens une erreur « ne
trouve pas libmachin.dll »
Je compile avec GCC (dans MinGW sous Windows). Je voudrais obtenir un
exécutable qui se suffise à lui-même,
Mais patatras : sous Win, si je tente de lancer l'exécutable
« statique » sur une machine n'ayant pas GTK+, j'obtiens une erreur « ne
trouve pas libmachin.dll »
> Mais patatras : sous Win, si je tente de lancer l'exécutable
> « statique » sur une machine n'ayant pas GTK+, j'obtiens une erreur « ne
> trouve pas libmachin.dll »
Cause la plus probable ÀMHA : tu as lié avec gtk.lib (ou libgtk.a sou s
Unix), mais le contenu de cette bibliothèque n'a pas lui-même été généré
avec l'option -static, et donc il [le contenu] dépend de certaines
bibliothèques dynamiques.
Sous Windows, l'éditeur de liens utilise (exclusivement) des
machintruc.lib; mais si dans le cas (ancien) de la liaison statique ce
fichier contenait des modules contenant eux-même du code objet, dans le
cas de la liaison dynamique le fichier .lib ne contient que des
pointeurs vers les entrées (les __dllimport__) de la .DLL associée ; on
appelle ce .lib un « bibliothèque d'importation ».
Au passage, le fichier .def ne sert qu'à générer cette bibliothèq ue
d'importation. Résultat, tu ne peux pas savoir si un .lib est prévu p our
être lié statiquement ou dynamiquement.
Mais dans tous les cas, aucune des deux options de compilation, statique
ou dynamique, n'est automatiquement transitive, seul le choix par défau t
de l'une ou de l'autre l'est
En fait, le mouvement est récursif jusqu'à la bibliothèque standard
(libc.so/libc.a/libcXX.lib, dont la DLL associée s'appelle msvcrtXX.dll
sous Windows), voire même jusqu'à l'interface du système d'exploita tion
qui sous Windows est constitué d'entrées dynamiques... mais là, pou r
pouvoir lier avec le contenu statique il faudrait revenir 15 ans en
arrière, et travailler dans l'équipe de développement à Redmond !
> Mais patatras : sous Win, si je tente de lancer l'exécutable
> « statique » sur une machine n'ayant pas GTK+, j'obtiens une erreur « ne
> trouve pas libmachin.dll »
Cause la plus probable ÀMHA : tu as lié avec gtk.lib (ou libgtk.a sou s
Unix), mais le contenu de cette bibliothèque n'a pas lui-même été généré
avec l'option -static, et donc il [le contenu] dépend de certaines
bibliothèques dynamiques.
Sous Windows, l'éditeur de liens utilise (exclusivement) des
machintruc.lib; mais si dans le cas (ancien) de la liaison statique ce
fichier contenait des modules contenant eux-même du code objet, dans le
cas de la liaison dynamique le fichier .lib ne contient que des
pointeurs vers les entrées (les __dllimport__) de la .DLL associée ; on
appelle ce .lib un « bibliothèque d'importation ».
Au passage, le fichier .def ne sert qu'à générer cette bibliothèq ue
d'importation. Résultat, tu ne peux pas savoir si un .lib est prévu p our
être lié statiquement ou dynamiquement.
Mais dans tous les cas, aucune des deux options de compilation, statique
ou dynamique, n'est automatiquement transitive, seul le choix par défau t
de l'une ou de l'autre l'est
En fait, le mouvement est récursif jusqu'à la bibliothèque standard
(libc.so/libc.a/libcXX.lib, dont la DLL associée s'appelle msvcrtXX.dll
sous Windows), voire même jusqu'à l'interface du système d'exploita tion
qui sous Windows est constitué d'entrées dynamiques... mais là, pou r
pouvoir lier avec le contenu statique il faudrait revenir 15 ans en
arrière, et travailler dans l'équipe de développement à Redmond !
> Mais patatras : sous Win, si je tente de lancer l'exécutable
> « statique » sur une machine n'ayant pas GTK+, j'obtiens une erreur « ne
> trouve pas libmachin.dll »
Cause la plus probable ÀMHA : tu as lié avec gtk.lib (ou libgtk.a sou s
Unix), mais le contenu de cette bibliothèque n'a pas lui-même été généré
avec l'option -static, et donc il [le contenu] dépend de certaines
bibliothèques dynamiques.
Sous Windows, l'éditeur de liens utilise (exclusivement) des
machintruc.lib; mais si dans le cas (ancien) de la liaison statique ce
fichier contenait des modules contenant eux-même du code objet, dans le
cas de la liaison dynamique le fichier .lib ne contient que des
pointeurs vers les entrées (les __dllimport__) de la .DLL associée ; on
appelle ce .lib un « bibliothèque d'importation ».
Au passage, le fichier .def ne sert qu'à générer cette bibliothèq ue
d'importation. Résultat, tu ne peux pas savoir si un .lib est prévu p our
être lié statiquement ou dynamiquement.
Mais dans tous les cas, aucune des deux options de compilation, statique
ou dynamique, n'est automatiquement transitive, seul le choix par défau t
de l'une ou de l'autre l'est
En fait, le mouvement est récursif jusqu'à la bibliothèque standard
(libc.so/libc.a/libcXX.lib, dont la DLL associée s'appelle msvcrtXX.dll
sous Windows), voire même jusqu'à l'interface du système d'exploita tion
qui sous Windows est constitué d'entrées dynamiques... mais là, pou r
pouvoir lier avec le contenu statique il faudrait revenir 15 ans en
arrière, et travailler dans l'équipe de développement à Redmond !
Ce qui m'épate, c'est que la compilation lie une DLL alors que j'ai
précisé -static. Je me serais attendu à obtenir un message d'erreur
(ou au pire un warning).
On 9 mar, 13:49, Antoine Leca wrote:En fait, le mouvement est récursif jusqu'à la bibliothèque standard
[...] voire même jusqu'à l'interface du système d'exploitation [...]
Quand on arrive à ce niveau c'est plutôt une bonne chose, non ? J'ai
l'impression que sans ce comportement, un exécutable produit sous une
version de l'OS (disons XP) ne marcherait pas sous une autre (mettons
Win 2000).
Merci pour toutes ces infos. As-tu une idée de ce que peuvent être les
fichiers .dll.a ?
Ce qui m'épate, c'est que la compilation lie une DLL alors que j'ai
précisé -static. Je me serais attendu à obtenir un message d'erreur
(ou au pire un warning).
On 9 mar, 13:49, Antoine Leca <r...@localhost.invalid> wrote:
En fait, le mouvement est récursif jusqu'à la bibliothèque standard
[...] voire même jusqu'à l'interface du système d'exploitation [...]
Quand on arrive à ce niveau c'est plutôt une bonne chose, non ? J'ai
l'impression que sans ce comportement, un exécutable produit sous une
version de l'OS (disons XP) ne marcherait pas sous une autre (mettons
Win 2000).
Merci pour toutes ces infos. As-tu une idée de ce que peuvent être les
fichiers .dll.a ?
Ce qui m'épate, c'est que la compilation lie une DLL alors que j'ai
précisé -static. Je me serais attendu à obtenir un message d'erreur
(ou au pire un warning).
On 9 mar, 13:49, Antoine Leca wrote:En fait, le mouvement est récursif jusqu'à la bibliothèque standard
[...] voire même jusqu'à l'interface du système d'exploitation [...]
Quand on arrive à ce niveau c'est plutôt une bonne chose, non ? J'ai
l'impression que sans ce comportement, un exécutable produit sous une
version de l'OS (disons XP) ne marcherait pas sous une autre (mettons
Win 2000).
Merci pour toutes ces infos. As-tu une idée de ce que peuvent être les
fichiers .dll.a ?