Je précise que je n'avais aucun problème avec ProjectBuilder.
Le problème est le suivant :
je crée un nouveau projet Carbon ~/test
(il crée par défaut un fichier main.c avec quelques trucs)
je compile, ça marche.
Il a créé l'application sous ~/test/build/test
J'efface ~/test/build/test.build (un dossier à côté de l'application)
J'essaie d'ouvrir le produit ~/test/build/test et ça plante.
J'obtiens le message suivant dans la console :
dyld: /Users/jsalort/test/build/test.app/Contents/MacOS/test can't open
library:
/Users/jsalort/test/build/test.build/test.build/Objects-normal/ppc/libst
dc++_ZeroLink.dylib (No such file or directory, errno = 2)
Il semble donc que l'application créée par XCode dépende du fichier
extérieur
~/test/build/test.build/test.build/Objects-normal/ppc/libstdc++_ZeroLink
.dylib
Comment faire pour que ce ne soit pas le cas ? (c'est-à-dire avoir une
application autonome !)
Comment se fait-il qu'une telle chose se produise ?
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
lists
Julien Salort wrote:
Bonjour,
Je précise que je n'avais aucun problème avec ProjectBuilder.
C'est bon j'ai trouvé. Il faut changer le Development Style en Deployment.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Julien Salort <lists@juliensalort.org> wrote:
Bonjour,
Je précise que je n'avais aucun problème avec ProjectBuilder.
C'est bon j'ai trouvé.
Il faut changer le Development Style en Deployment.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Je précise que je n'avais aucun problème avec ProjectBuilder.
C'est bon j'ai trouvé. Il faut changer le Development Style en Deployment.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Patrick Stadelmann
In article <1geiqh2.1vozgdf2b9tq8N%, (Julien Salort) wrote:
Comment se fait-il qu'une telle chose se produise ?
Ca s'appelle ZeroLink et ça fait exactement ça : ca permet de lancer l'appli en mode debug sans la linker auparavant, ce qui permet de gagner du temps.
Il me semble qu'il n'est actif que pour le mode "debug" et pas pour le mode "deployment".
Patrick -- Patrick Stadelmann
In article <1geiqh2.1vozgdf2b9tq8N%lists@juliensalort.org>,
lists@juliensalort.org (Julien Salort) wrote:
Comment se fait-il qu'une telle chose se produise ?
Ca s'appelle ZeroLink et ça fait exactement ça : ca permet de lancer
l'appli en mode debug sans la linker auparavant, ce qui permet de gagner
du temps.
In article <1geiqh2.1vozgdf2b9tq8N%, (Julien Salort) wrote:
Comment se fait-il qu'une telle chose se produise ?
Ca s'appelle ZeroLink et ça fait exactement ça : ca permet de lancer l'appli en mode debug sans la linker auparavant, ce qui permet de gagner du temps.
Il me semble qu'il n'est actif que pour le mode "debug" et pas pour le mode "deployment".
Patrick -- Patrick Stadelmann
lists
Patrick Stadelmann wrote:
Ca s'appelle ZeroLink et ça fait exactement ça : ca permet de lancer l'appli en mode debug sans la linker auparavant, ce qui permet de gagner du temps.
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est plutôt la compilation que le linkage. Par conséquent, je ne sais pas si cette méthode permet vraiment un gain de temps vraiment substantiel.
Quelqu'un a déjà fait des mesures pour quantifier le gain de temps ?
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Ca s'appelle ZeroLink et ça fait exactement ça : ca permet de lancer
l'appli en mode debug sans la linker auparavant, ce qui permet de gagner
du temps.
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est
plutôt la compilation que le linkage. Par conséquent, je ne sais pas si
cette méthode permet vraiment un gain de temps vraiment substantiel.
Quelqu'un a déjà fait des mesures pour quantifier le gain de temps ?
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Ca s'appelle ZeroLink et ça fait exactement ça : ca permet de lancer l'appli en mode debug sans la linker auparavant, ce qui permet de gagner du temps.
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est plutôt la compilation que le linkage. Par conséquent, je ne sais pas si cette méthode permet vraiment un gain de temps vraiment substantiel.
Quelqu'un a déjà fait des mesures pour quantifier le gain de temps ?
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Patrick Stadelmann
In article <1gejhdz.1jco81114rj2kiN%, (Julien Salort) wrote:
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est plutôt la compilation que le linkage. Par conséquent, je ne sais pas si cette méthode permet vraiment un gain de temps vraiment substantiel.
Pendant le debug, normalement tu ne modifies qu'un fichier à la fois, donc la compilation est très rapide.
Patrick -- Patrick Stadelmann
In article <1gejhdz.1jco81114rj2kiN%lists@juliensalort.org>,
lists@juliensalort.org (Julien Salort) wrote:
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est
plutôt la compilation que le linkage. Par conséquent, je ne sais pas si
cette méthode permet vraiment un gain de temps vraiment substantiel.
Pendant le debug, normalement tu ne modifies qu'un fichier à la fois,
donc la compilation est très rapide.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gejhdz.1jco81114rj2kiN%, (Julien Salort) wrote:
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est plutôt la compilation que le linkage. Par conséquent, je ne sais pas si cette méthode permet vraiment un gain de temps vraiment substantiel.
Pendant le debug, normalement tu ne modifies qu'un fichier à la fois, donc la compilation est très rapide.
Patrick -- Patrick Stadelmann
patrox
ne *Jamais* utiliser ZERO LINK
Utiliser codewarrior a la place, sinon de gros problemes t'attendent au tournant...
xCode ne gere pas le dead code stripping, ce qui pose d'enorme problemes dans le cas de fonctions inutilisées ( surtout si tu fourni des libraries... )
pat.
ne *Jamais* utiliser ZERO LINK
Utiliser codewarrior a la place, sinon de gros problemes t'attendent au
tournant...
xCode ne gere pas le dead code stripping, ce qui pose d'enorme problemes
dans le cas de fonctions inutilisées ( surtout si tu fourni des
libraries... )
Utiliser codewarrior a la place, sinon de gros problemes t'attendent au tournant...
xCode ne gere pas le dead code stripping, ce qui pose d'enorme problemes dans le cas de fonctions inutilisées ( surtout si tu fourni des libraries... )
pat.
Patrick Stadelmann
In article <40b84b39$0$307$, "patrox" wrote:
ne *Jamais* utiliser ZERO LINK
???
Utiliser codewarrior a la place, sinon de gros problemes t'attendent au tournant...
???
xCode ne gere pas le dead code stripping, ce qui pose d'enorme problemes dans le cas de fonctions inutilisées ( surtout si tu fourni des libraries... )
Quel rapport avec ZeroLink ? Et ça se corrige en spécifiant la liste des symboles a exporter.
Patrick -- Patrick Stadelmann
In article <40b84b39$0$307$7a628cd7@news.club-internet.fr>,
"patrox" <misterbanned@hotmail.com> wrote:
ne *Jamais* utiliser ZERO LINK
???
Utiliser codewarrior a la place, sinon de gros problemes t'attendent au
tournant...
???
xCode ne gere pas le dead code stripping, ce qui pose d'enorme problemes
dans le cas de fonctions inutilisées ( surtout si tu fourni des
libraries... )
Quel rapport avec ZeroLink ? Et ça se corrige en spécifiant la liste des
symboles a exporter.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Utiliser codewarrior a la place, sinon de gros problemes t'attendent au tournant...
???
xCode ne gere pas le dead code stripping, ce qui pose d'enorme problemes dans le cas de fonctions inutilisées ( surtout si tu fourni des libraries... )
Quel rapport avec ZeroLink ? Et ça se corrige en spécifiant la liste des symboles a exporter.
Patrick -- Patrick Stadelmann
ol.g+news
Julien Salort wrote:
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est plutôt la compilation que le linkage. Par conséquent, je ne sais pas si cette méthode permet vraiment un gain de temps vraiment substantiel.
Quelqu'un a déjà fait des mesures pour quantifier le gain de temps ?
Dès que tu commences à avoir un nombre de fichiers conséquents, le gain est assez spectaculaire, et les cycles correction/compil/exécution sont plus confortables. Evidemment c'est un outil qui n'a du sens -uniquement- en développement, vu que l'appli référencent les chemins complets vers chaque .o
Il faut aussi faire attention: les erreurs normalement chopées au link ne le seront pas (et pour cause) avec ZeroLink (symboles manquants, dupliqués, etc), les initialiseurs statiques C++ ou les +load Obj-C doivent être appelés explicitement si besoin, etc. Donc un build occasionnel en deployment est conseillé.
Ol. -- Olivier Gutknecht
Julien Salort <lists@juliensalort.org> wrote:
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est
plutôt la compilation que le linkage. Par conséquent, je ne sais pas si
cette méthode permet vraiment un gain de temps vraiment substantiel.
Quelqu'un a déjà fait des mesures pour quantifier le gain de temps ?
Dès que tu commences à avoir un nombre de fichiers conséquents, le gain
est assez spectaculaire, et les cycles correction/compil/exécution sont
plus confortables. Evidemment c'est un outil qui n'a du sens
-uniquement- en développement, vu que l'appli référencent les chemins
complets vers chaque .o
Il faut aussi faire attention: les erreurs normalement chopées au link
ne le seront pas (et pour cause) avec ZeroLink (symboles manquants,
dupliqués, etc), les initialiseurs statiques C++ ou les +load Obj-C
doivent être appelés explicitement si besoin, etc. Donc un build
occasionnel en deployment est conseillé.
Cependant, ce qui prend le plus de temps (en tout cas chez moi), c'est plutôt la compilation que le linkage. Par conséquent, je ne sais pas si cette méthode permet vraiment un gain de temps vraiment substantiel.
Quelqu'un a déjà fait des mesures pour quantifier le gain de temps ?
Dès que tu commences à avoir un nombre de fichiers conséquents, le gain est assez spectaculaire, et les cycles correction/compil/exécution sont plus confortables. Evidemment c'est un outil qui n'a du sens -uniquement- en développement, vu que l'appli référencent les chemins complets vers chaque .o
Il faut aussi faire attention: les erreurs normalement chopées au link ne le seront pas (et pour cause) avec ZeroLink (symboles manquants, dupliqués, etc), les initialiseurs statiques C++ ou les +load Obj-C doivent être appelés explicitement si besoin, etc. Donc un build occasionnel en deployment est conseillé.
Ol. -- Olivier Gutknecht
DINH Viêt Hoà
Dès que tu commences à avoir un nombre de fichiers conséquents, le gain est assez spectaculaire, et les cycles correction/compil/exécution sont plus confortables. Evidemment c'est un outil qui n'a du sens -uniquement- en développement, vu que l'appli référencent les chemins complets vers chaque .o
Il faut aussi faire attention: les erreurs normalement chopées au link ne le seront pas (et pour cause) avec ZeroLink (symboles manquants, dupliqués, etc), les initialiseurs statiques C++ ou les +load Obj-C doivent être appelés explicitement si besoin, etc. Donc un build occasionnel en deployment est conseillé.
et autre chose, quand tu utilises zerolink, tu ne disposes pas facilement des symboles de débogage lorsque tu essaies d'utiliser gdb pour analyser un fichier "core" (core dump, analyse post-mortem d'un programme).
C'est sans doute possible de les avoir, mais je n'ai pas beaucoup cherché non plus ...
-- DINH V. Hoa,
"on dirait un gamin de 2 ans" -- coin-coin
Dès que tu commences à avoir un nombre de fichiers conséquents, le gain
est assez spectaculaire, et les cycles correction/compil/exécution sont
plus confortables. Evidemment c'est un outil qui n'a du sens
-uniquement- en développement, vu que l'appli référencent les chemins
complets vers chaque .o
Il faut aussi faire attention: les erreurs normalement chopées au link
ne le seront pas (et pour cause) avec ZeroLink (symboles manquants,
dupliqués, etc), les initialiseurs statiques C++ ou les +load Obj-C
doivent être appelés explicitement si besoin, etc. Donc un build
occasionnel en deployment est conseillé.
et autre chose, quand tu utilises zerolink, tu ne disposes pas
facilement des symboles de débogage lorsque tu essaies d'utiliser gdb
pour analyser un fichier "core" (core dump, analyse post-mortem d'un
programme).
C'est sans doute possible de les avoir, mais je n'ai pas beaucoup
cherché non plus ...
Dès que tu commences à avoir un nombre de fichiers conséquents, le gain est assez spectaculaire, et les cycles correction/compil/exécution sont plus confortables. Evidemment c'est un outil qui n'a du sens -uniquement- en développement, vu que l'appli référencent les chemins complets vers chaque .o
Il faut aussi faire attention: les erreurs normalement chopées au link ne le seront pas (et pour cause) avec ZeroLink (symboles manquants, dupliqués, etc), les initialiseurs statiques C++ ou les +load Obj-C doivent être appelés explicitement si besoin, etc. Donc un build occasionnel en deployment est conseillé.
et autre chose, quand tu utilises zerolink, tu ne disposes pas facilement des symboles de débogage lorsque tu essaies d'utiliser gdb pour analyser un fichier "core" (core dump, analyse post-mortem d'un programme).
C'est sans doute possible de les avoir, mais je n'ai pas beaucoup cherché non plus ...
-- DINH V. Hoa,
"on dirait un gamin de 2 ans" -- coin-coin
ol.g+news
DINH Viêt Hoà wrote:
et autre chose, quand tu utilises zerolink, tu ne disposes pas facilement des symboles de débogage lorsque tu essaies d'utiliser gdb pour analyser un fichier "core" (core dump, analyse post-mortem d'un programme).
C'est sans doute possible de les avoir, mais je n'ai pas beaucoup cherché non plus ...
Faut p'têt loader indépendament tous les .o justement avant de faire l'analyse. Juste une idée comme ça, jamais essayé.
Ol. -- Olivier Gutknecht
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
et autre chose, quand tu utilises zerolink, tu ne disposes pas
facilement des symboles de débogage lorsque tu essaies d'utiliser gdb
pour analyser un fichier "core" (core dump, analyse post-mortem d'un
programme).
C'est sans doute possible de les avoir, mais je n'ai pas beaucoup
cherché non plus ...
Faut p'têt loader indépendament tous les .o justement avant de faire
l'analyse. Juste une idée comme ça, jamais essayé.
et autre chose, quand tu utilises zerolink, tu ne disposes pas facilement des symboles de débogage lorsque tu essaies d'utiliser gdb pour analyser un fichier "core" (core dump, analyse post-mortem d'un programme).
C'est sans doute possible de les avoir, mais je n'ai pas beaucoup cherché non plus ...
Faut p'têt loader indépendament tous les .o justement avant de faire l'analyse. Juste une idée comme ça, jamais essayé.
