2008-12-04 10 views
2

J'ai une question liée à la façon dont les chemins relatifs sont interprétés dans divers environnements. Si je dispose d'un code C à compiler sur Linux en utilisant Makefile et gcc, et si un fichier source a:Interprétation de chemin relatif sur linux -gcc env

fopen(“../../xyz.ctl”, ”r”); 

où ce fichier doit se trouver. En d'autres termes, si j'ai

fopen(“xyz.ctl” , ”r”); 

serait le look du compilateur pour xyz.ctl dans le même dossier que le: -.

a) Lorsque le fichier source ayant cette déclaration fopen est présent?

b.) Où le fichier makefile est-il présent? C) Où l'exécutable Linux serait-il généré?

Je sais que MSVC tous les chemins relatifs proviennent du dossier qui contient * .dsw (fichier d'espace de travail). Pour l'environnement RVDS, il commence à partir du dossier où l'exécutable * .axf est généré.

-AD

+0

Pourquoi l'appel du compilateur va-t-il s'ouvrir? Votre code appelle cela. – leppie

Répondre

5

Votre fichier Makefile appelle gcc qui compile votre code contenant fopen(). fopen() est appelée lorsque vous exécutez le code nouvellement compilé. Le chemin est relatif à votre répertoire de travail actuel lorsque vous avez lancé le programme.

1

Le chemin dans le code compilé par un outil Unix est par rapport à la trajectoire dans laquelle l'exécutable final est exécutée. Gcc n'essaie pas de comprendre ce que vous faites et n'analyse pas les chemins que vous compilez dans votre application. Pour autant que je sache, la commande de copie Windows est la seule commande qui tente de "réparer" les chemins dans les applications sur lesquelles elle fonctionne. (Histoire: J'ai eu une application VB sur une disquette et quand je l'ai copié sur C :, la somme de contrôle du fichier avait changé.Un diff a montré que la copie de l'application sur le disque remplacerait "C: \" dans l'application à " A: \ "et vice versa).

Questions connexes