j'ai downloadé un exemple d'Apple (à propos de launchd) qui ne compile
pas pour une raison très simple : XCode ne trouve pas le header
"stdarg.h" qui est pourtant sur ma bécanne, par exemple là :
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin10/4.0.1/inc
lude/stdarg.h
(il y en a plusieurs verions, c'est un "classique")
que faire d'une manière générale dans ces cas là ?
c'est une histoire de PATH de recherche dans XCode ?
--
« Le verbe aimer est difficile à conjuguer :
son passé n'est pas simple, son présent n'est qu'indicatif,
et son futur est toujours conditionnel. »
(Jean Cocteau)
que faire d'une manière générale dans ces cas là ?
S'assurer que le SDK sélectionné dans XCode est bien le bon...
c'est une histoire de PATH de recherche dans XCode ?
En principe on n'a pas à se soucier de ce problème du moment que le b on SDK est sélectionné ;)
unbewusst.sein
Franck <franck+ wrote:
> que faire d'une manière générale dans ces cas là ?
S'assurer que le SDK sélectionné dans XCode est bien le bon...
> c'est une histoire de PATH de recherche dans XCode ?
En principe on n'a pas à se soucier de ce problème du moment que le bon SDK est sélectionné ;)
ben justement, c'est le bon ! avoir copié le "bon" header dans mon rep, ça compile bien MAIS ça se termine par "Segmentation Fault" sur un des deux exec...
j'ai lu qqpart que la version actuelle (chez moi Version 3.2.2) de XCode est "assez" buggée, une autre ne devrait pas tarder à sortir qui inclurait XCode + Interface Builder en une seule app. -- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Franck <franck+news@_remove_apoal.com> wrote:
> que faire d'une manière générale dans ces cas là ?
S'assurer que le SDK sélectionné dans XCode est bien le bon...
> c'est une histoire de PATH de recherche dans XCode ?
En principe on n'a pas à se soucier de ce problème du moment que le bon
SDK est sélectionné ;)
ben justement, c'est le bon !
avoir copié le "bon" header dans mon rep, ça compile bien MAIS ça se
termine par "Segmentation Fault" sur un des deux exec...
j'ai lu qqpart que la version actuelle (chez moi Version 3.2.2) de XCode
est "assez" buggée, une autre ne devrait pas tarder à sortir qui
inclurait XCode + Interface Builder en une seule app.
--
« La révolution ne supprime pas les privilèges,
elle se borne à changer les privilégiés. »
(Philippe Bouvard)
> que faire d'une manière générale dans ces cas là ?
S'assurer que le SDK sélectionné dans XCode est bien le bon...
> c'est une histoire de PATH de recherche dans XCode ?
En principe on n'a pas à se soucier de ce problème du moment que le bon SDK est sélectionné ;)
ben justement, c'est le bon ! avoir copié le "bon" header dans mon rep, ça compile bien MAIS ça se termine par "Segmentation Fault" sur un des deux exec...
j'ai lu qqpart que la version actuelle (chez moi Version 3.2.2) de XCode est "assez" buggée, une autre ne devrait pas tarder à sortir qui inclurait XCode + Interface Builder en une seule app. -- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Paul Gaborit
À (at) Wed, 9 Jun 2010 06:18:54 +0200, (Une Bévue) écrivait (wrote):
j'ai downloadé un exemple d'Apple (à propos de launchd) qui ne compile pas pour une raison très simple : XCode ne trouve pas le header "stdarg.h" qui est pourtant sur ma bécanne, par exemple là : /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin10/4.0.1/inc lude/stdarg.h
(il y en a plusieurs verions, c'est un "classique")
que faire d'une manière générale dans ces cas là ? c'est une histoire de PATH de recherche dans XCode ?
Plutôt un truc lié à gcc. Que dit la commande suivante :
% gcc -print-search-dirs
PS: XCode est-il à jour ? La version courante de gcc pour 10.6 est plutôt la version 4.2.1 que la 4.0.1.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 9 Jun 2010 06:18:54 +0200,
unbewusst.sein@google.com.invalid (Une Bévue) écrivait (wrote):
j'ai downloadé un exemple d'Apple (à propos de launchd) qui ne compile
pas pour une raison très simple : XCode ne trouve pas le header
"stdarg.h" qui est pourtant sur ma bécanne, par exemple là :
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin10/4.0.1/inc
lude/stdarg.h
(il y en a plusieurs verions, c'est un "classique")
que faire d'une manière générale dans ces cas là ?
c'est une histoire de PATH de recherche dans XCode ?
Plutôt un truc lié à gcc. Que dit la commande suivante :
% gcc -print-search-dirs
PS: XCode est-il à jour ? La version courante de gcc pour 10.6 est
plutôt la version 4.2.1 que la 4.0.1.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 9 Jun 2010 06:18:54 +0200, (Une Bévue) écrivait (wrote):
j'ai downloadé un exemple d'Apple (à propos de launchd) qui ne compile pas pour une raison très simple : XCode ne trouve pas le header "stdarg.h" qui est pourtant sur ma bécanne, par exemple là : /Developer/SDKs/MacOSX10.6.sdk/usr/lib/gcc/i686-apple-darwin10/4.0.1/inc lude/stdarg.h
(il y en a plusieurs verions, c'est un "classique")
que faire d'une manière générale dans ces cas là ? c'est une histoire de PATH de recherche dans XCode ?
Plutôt un truc lié à gcc. Que dit la commande suivante :
% gcc -print-search-dirs
PS: XCode est-il à jour ? La version courante de gcc pour 10.6 est plutôt la version 4.2.1 que la 4.0.1.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
unbewusst.sein
Paul Gaborit wrote:
Plutôt un truc lié à gcc. Que dit la commande suivante :
moi j'ai utilisé celui ci : zsh-% locate stdarg.h /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framewo rk/Versions/A/Headers/stdarg.h
ie copié dans le rép du projet, mais bon ça se termine par un "Segmentation fault" alors que le projet vient de chez Mr Apple...
dans le projet c'est bien le "SDKs/MacOSX10.4u.sdk" qui est choisi.
PS: XCode est-il à jour ? La version courante de gcc pour 10.6 est plutôt la version 4.2.1 que la 4.0.1.
moi j'ai XCode Version 3.2.2 : Component versions Xcode IDE: 1650.0 Xcode Core: 1648.0 ToolSupport: 1631.0
téléchargée le 14 05 2010... -- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Plutôt un truc lié à gcc. Que dit la commande suivante :
moi j'ai utilisé celui ci :
zsh-% locate stdarg.h
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framewo
rk/Versions/A/Headers/stdarg.h
ie copié dans le rép du projet, mais bon ça se termine par un
"Segmentation fault" alors que le projet vient de chez Mr Apple...
dans le projet c'est bien le "SDKs/MacOSX10.4u.sdk" qui est choisi.
PS: XCode est-il à jour ? La version courante de gcc pour 10.6 est
plutôt la version 4.2.1 que la 4.0.1.
moi j'ai XCode Version 3.2.2 :
Component versions
Xcode IDE: 1650.0
Xcode Core: 1648.0
ToolSupport: 1631.0
téléchargée le 14 05 2010...
--
« La révolution ne supprime pas les privilèges,
elle se borne à changer les privilégiés. »
(Philippe Bouvard)
moi j'ai utilisé celui ci : zsh-% locate stdarg.h /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framewo rk/Versions/A/Headers/stdarg.h
ie copié dans le rép du projet, mais bon ça se termine par un "Segmentation fault" alors que le projet vient de chez Mr Apple...
dans le projet c'est bien le "SDKs/MacOSX10.4u.sdk" qui est choisi.
PS: XCode est-il à jour ? La version courante de gcc pour 10.6 est plutôt la version 4.2.1 que la 4.0.1.
moi j'ai XCode Version 3.2.2 : Component versions Xcode IDE: 1650.0 Xcode Core: 1648.0 ToolSupport: 1631.0
téléchargée le 14 05 2010... -- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Franck
On 09/06/2010 09:56, Une Bévue wrote:
j'ai lu qqpart que la version actuelle (chez moi Version 3.2.2) de XCod e est "assez" buggée, une autre ne devrait pas tarder à sortir qui inclurait XCode + Interface Builder en une seule app.
Des échos que j'ai eu de connaissances actuellement à la WWDC, cette future version (XCode 4) en est vraiment à ses débuts, n'est pas vraiment exploitable, et ne devrait pas être disponible avant de nombreux mois...
Et j'utilise XCode 3.2.2 (et même 3.2.3 en tant que dev iPhone enregistré) régulièrement sans qu'il ne pose trop de problèmes (m ême si effectivement il plante parfois).
On 09/06/2010 09:56, Une Bévue wrote:
j'ai lu qqpart que la version actuelle (chez moi Version 3.2.2) de XCod e
est "assez" buggée, une autre ne devrait pas tarder à sortir qui
inclurait XCode + Interface Builder en une seule app.
Des échos que j'ai eu de connaissances actuellement à la WWDC, cette
future version (XCode 4) en est vraiment à ses débuts, n'est pas
vraiment exploitable, et ne devrait pas être disponible avant de
nombreux mois...
Et j'utilise XCode 3.2.2 (et même 3.2.3 en tant que dev iPhone
enregistré) régulièrement sans qu'il ne pose trop de problèmes (m ême si
effectivement il plante parfois).
j'ai lu qqpart que la version actuelle (chez moi Version 3.2.2) de XCod e est "assez" buggée, une autre ne devrait pas tarder à sortir qui inclurait XCode + Interface Builder en une seule app.
Des échos que j'ai eu de connaissances actuellement à la WWDC, cette future version (XCode 4) en est vraiment à ses débuts, n'est pas vraiment exploitable, et ne devrait pas être disponible avant de nombreux mois...
Et j'utilise XCode 3.2.2 (et même 3.2.3 en tant que dev iPhone enregistré) régulièrement sans qu'il ne pose trop de problèmes (m ême si effectivement il plante parfois).
unbewusst.sein
Une Bévue wrote:
> PS: XCode est-il à jour ? La version courante de gcc pour 10.6 est > plutôt la version 4.2.1 que la 4.0.1.
-- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
unbewusst.sein
Franck <franck+ wrote:
Des échos que j'ai eu de connaissances actuellement à la WWDC, cette future version (XCode 4) en est vraiment à ses débuts, n'est pas vraiment exploitable, et ne devrait pas être disponible avant de nombreux mois...
bon, ça ne m'étonne pas.
Et j'utilise XCode 3.2.2 (et même 3.2.3 en tant que dev iPhone enregistré) régulièrement sans qu'il ne pose trop de problèmes (même si effectivement il plante parfois).
à part les pbs de headers non trouvés (mais de projet made in Apple au temps <= 10.4) je n'ai eu qu'un pb mais avec IB qui me présente la fenêtre dans l'orde inverse au run de celui demandé sous IB. -- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Franck <franck+news@_remove_apoal.com> wrote:
Des échos que j'ai eu de connaissances actuellement à la WWDC, cette
future version (XCode 4) en est vraiment à ses débuts, n'est pas
vraiment exploitable, et ne devrait pas être disponible avant de
nombreux mois...
bon, ça ne m'étonne pas.
Et j'utilise XCode 3.2.2 (et même 3.2.3 en tant que dev iPhone
enregistré) régulièrement sans qu'il ne pose trop de problèmes (même si
effectivement il plante parfois).
à part les pbs de headers non trouvés (mais de projet made in Apple au
temps <= 10.4) je n'ai eu qu'un pb mais avec IB qui me présente la
fenêtre dans l'orde inverse au run de celui demandé sous IB.
--
« La révolution ne supprime pas les privilèges,
elle se borne à changer les privilégiés. »
(Philippe Bouvard)
Des échos que j'ai eu de connaissances actuellement à la WWDC, cette future version (XCode 4) en est vraiment à ses débuts, n'est pas vraiment exploitable, et ne devrait pas être disponible avant de nombreux mois...
bon, ça ne m'étonne pas.
Et j'utilise XCode 3.2.2 (et même 3.2.3 en tant que dev iPhone enregistré) régulièrement sans qu'il ne pose trop de problèmes (même si effectivement il plante parfois).
à part les pbs de headers non trouvés (mais de projet made in Apple au temps <= 10.4) je n'ai eu qu'un pb mais avec IB qui me présente la fenêtre dans l'orde inverse au run de celui demandé sous IB. -- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Paul Gaborit
À (at) Wed, 9 Jun 2010 10:55:17 +0200, (Une Bévue) écrivait (wrote):
Paul Gaborit wrote:
Plutôt un truc lié à gcc. Que dit la commande suivante :
moi j'ai utilisé celui ci : zsh-% locate stdarg.h /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framewo rk/Versions/A/Headers/stdarg.h
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et tout le package developper) est mal installé.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 9 Jun 2010 10:55:17 +0200,
unbewusst.sein@google.com.invalid (Une Bévue) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Plutôt un truc lié à gcc. Que dit la commande suivante :
moi j'ai utilisé celui ci :
zsh-% locate stdarg.h
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framewo
rk/Versions/A/Headers/stdarg.h
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au
compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et
tout le package developper) est mal installé.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
moi j'ai utilisé celui ci : zsh-% locate stdarg.h /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/Kernel.framewo rk/Versions/A/Headers/stdarg.h
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et tout le package developper) est mal installé.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
unbewusst.sein
Paul Gaborit wrote:
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et tout le package developper) est mal installé.
il existe ce fichier, installé par un installer Apple.
bon, ben ce path "/usr/lib/gcc/i686-apple-darwin10/4.2.1/" est bien dans le path du gcc (librairies) que j'utilise, je ne pige pas pourquoi gcc ne l'a pas trouvé alors.
bon après nouvelle compil, plus de seg fault et ça roule...
merci !
-- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au
compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et
tout le package developper) est mal installé.
il existe ce fichier, installé par un installer Apple.
bon, ben ce path "/usr/lib/gcc/i686-apple-darwin10/4.2.1/" est bien dans
le path du gcc (librairies) que j'utilise, je ne pige pas pourquoi gcc
ne l'a pas trouvé alors.
bon après nouvelle compil, plus de seg fault et ça roule...
merci !
--
« La révolution ne supprime pas les privilèges,
elle se borne à changer les privilégiés. »
(Philippe Bouvard)
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et tout le package developper) est mal installé.
il existe ce fichier, installé par un installer Apple.
bon, ben ce path "/usr/lib/gcc/i686-apple-darwin10/4.2.1/" est bien dans le path du gcc (librairies) que j'utilise, je ne pige pas pourquoi gcc ne l'a pas trouvé alors.
bon après nouvelle compil, plus de seg fault et ça roule...
merci !
-- « La révolution ne supprime pas les privilèges, elle se borne à changer les privilégiés. » (Philippe Bouvard)
Paul Gaborit
À (at) Wed, 9 Jun 2010 14:14:42 +0200, (Une Bévue) écrivait (wrote):
Paul Gaborit wrote:
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et tout le package developper) est mal installé.
il existe ce fichier, installé par un installer Apple.
bon, ben ce path "/usr/lib/gcc/i686-apple-darwin10/4.2.1/" est bien dans le path du gcc (librairies) que j'utilise, je ne pige pas pourquoi gcc ne l'a pas trouvé alors.
Mais, ça, c'est pour les libraries (les bibliothèques).
Là ce qui nous intéresse, ce sont les chemins utilisés par le préprocesseur (le truc qui traite les directives #...). Je viens de retrouver la commande pour les obtenir :
% echo "" | gcc -c -E -v -
La liste des chemins utilisés suit la ligne :
#include <...> search starts here:
bon après nouvelle compil, plus de seg fault et ça roule...
C'est un progrès ! ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 9 Jun 2010 14:14:42 +0200,
unbewusst.sein@google.com.invalid (Une Bévue) écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au
compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est
/usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et
tout le package developper) est mal installé.
il existe ce fichier, installé par un installer Apple.
bon, ben ce path "/usr/lib/gcc/i686-apple-darwin10/4.2.1/" est bien dans
le path du gcc (librairies) que j'utilise, je ne pige pas pourquoi gcc
ne l'a pas trouvé alors.
Mais, ça, c'est pour les libraries (les bibliothèques).
Là ce qui nous intéresse, ce sont les chemins utilisés par le
préprocesseur (le truc qui traite les directives #...). Je viens de
retrouver la commande pour les obtenir :
% echo "" | gcc -c -E -v -
La liste des chemins utilisés suit la ligne :
#include <...> search starts here:
bon après nouvelle compil, plus de seg fault et ça roule...
C'est un progrès ! ;-)
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 9 Jun 2010 14:14:42 +0200, (Une Bévue) écrivait (wrote):
Paul Gaborit wrote:
Ne jamais faire cela avec stdarg.h ! Il *faut* absolument celui lié au compilateur *et* au système.
Le fichier stdarg.h correct pour votre gcc est /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stdarg.h
Si ce fichier n'existe pas, c'est que gcc (et donc sans doute XCode et tout le package developper) est mal installé.
il existe ce fichier, installé par un installer Apple.
bon, ben ce path "/usr/lib/gcc/i686-apple-darwin10/4.2.1/" est bien dans le path du gcc (librairies) que j'utilise, je ne pige pas pourquoi gcc ne l'a pas trouvé alors.
Mais, ça, c'est pour les libraries (les bibliothèques).
Là ce qui nous intéresse, ce sont les chemins utilisés par le préprocesseur (le truc qui traite les directives #...). Je viens de retrouver la commande pour les obtenir :
% echo "" | gcc -c -E -v -
La liste des chemins utilisés suit la ligne :
#include <...> search starts here:
bon après nouvelle compil, plus de seg fault et ça roule...
C'est un progrès ! ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>