erreur gcc : error: stray '\1' in program
Bonjour,
Un problème de compilation dont je ne me sors pas tout seul, même après des recherches sur internet (en anglais). J'ai une liste interminable d'erreurs à la compil (gcc -c), du type:
Code:
1
2
3
4
5
| In file included from dice.h:1:0,
from dice.c:1:
../toolkit/toolkit:1:1: error: stray ‘\’ in program
../toolkit/toolkit:1:1: error: stray ‘\177’ in program
... et des tonnes come ça ... |
J'ai aussi des variantes du genre (aussi en quantité impressionnante):
Code:
1
2
| ../toolkit/toolkit:34:3: error: stray ‘@’ in program
../toolkit/toolkit:34:640: warning: null character(s) ignored [enabled by default] |
Pour info, ma commande de compil est juste:
Code:
gcc -c -Wall dice.c
Cela survient à la compilation d'un petit source 'dice.c' qui inclut son 'dice.h' qui lui-même inclut uniquement mon 'toolkit' habituel (avec ses .c & .h). Le compilo me dit donc que l'erreur provient du module toolkit inclut. Or, toolkit.c compile très bien tout seul (et il build aussi très bien si j'ajoute un main()).
Donc, logiquement, l'erreur ne vient pas de là. Le message semble vouloir dire que mes sources contiennent des caractères ASCII non valides, ou pas ASCII du tout (> 0x7F=127). Les recherches sur internet m'ont confirmé cela: en général, les gens ont eu ces erreurs en copiant-collant du code qui était passé par par un logiciel (genre MS Word) qui transforme le source sans le dire (genre les quotes deviennent de vrais guillemets dont le code Unicode est bien loin de l'ASCII). Or, mes sources ont été tapées à la main exclusivement. Même si mon éditeur est configuré en 'utf-8, tant que je ne tape que de l'ASCII, cela ne pose théoriquement pas de problème.
Pour vérifier néanmoins, j'ai passé la totalité des sources pertinentes à la moulinette d'un petit script python qui contrôle cela: chaque caractère doit être de l'ASCII visible (0x20<c<0x7E) ou LF ou TAB (utilisé pour la tabulation 'inline'). Bon, je vous montre ce script pour être sûr et certain, mais je crois qu'il ne vous dira rien de plus:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| #! python
# coding:utf8
def check (filenames) :
for filename in filenames :
s = file(filename).read()
# juste pour vérifier qu'il passe bien par là
i = s.find('\n')
print (filename, s[:i])
# contrôle des caractères: ASCII visible, ou LF ou TAB
for (i,ch) in enumerate(s) :
c = ord(ch) # code ASCII
if (c != 0xA) and (c != 0x9) and ((c < 0x20) or (c > 0xFE)) :
print "index:%s code:%s char:'%s'" %(i,c,ch)
dice_c = "dice.c"
dice_h = "dice.h"
toolkit_c = "../toolkit/toolkit.c"
toolkit_h = "../toolkit/toolkit.h"
filenames = [dice_c , dice_h , toolkit_c , toolkit_h]
check (filenames) |
Là, je suis bloqué... :(
Merci à vous,
denis
PS: je viens de tomber sur un nouveau message en ligne au sujet de ces erreurs, sur stack-overflow: http://stackoverflow.com/questions/1...nnn-in-program. Le gars a suivi à peu près la même démarche que moi, y compris passer les sources dans un hex editor:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| The following issue popped up in my open source library, and I can't figure out
what's going on.
Two of my users have (gcc) compiler errors that look like:
/home/someone/Source/src/._regex.cpp:1:1: warning: null character(s) ignored
/home/someone/Source/src/._regex.cpp:1: error: stray ‘\5’ in program
/home/someone/Source/src/._regex.cpp:1: error: stray ‘\26’ in program
/home/someone/Source/src/._regex.cpp:1: error: stray ‘\7’ in program
/home/someone/Source/src/._regex.cpp:1:5: warning: null character(s) ignored
/home/someone/Source/src/._regex.cpp:1: error: stray ‘\2’ in program
...
I can't reproduce these errors; the code compiles fine on all machines I've tested.
Googling around seemed to indicate that this is often a result of a strange encoding or strange formatting,
but I ran all the source through a hex editor, and all characters are either printable ASCII (0x20 - 0x7E),
or tab, or newline. That's it.
Also, both users successfully compiled the previous version of the library; but the particular file in question
(regex.cpp) and its header files haven't been modified since that time! |
Mais les réponses ne me donnent aucune piste: il s'agit chez lui de fichiers annexes automatiquement générés par MacOSX qui ont un format tels (._*.c) qu'ils se retrouvent en-glob-és (sic!) par les commandes de compil à la make/makefile (le danger de patterns (motifs regex) trop généraux).
