error: stray '\377' in program

cygwin編譯報錯：**.cpp:1:1: error: stray '\377' in program解決方法

2014-06-12 00:41 2061人閱讀 評論(1) 收藏 舉報

編譯報錯內容：

[armeabi] Compile++ thumb: cocos2dcpp_shared <= HelloWorldScene.cpp

jni/../../Classes/HelloWorldScene.cpp:1:1: error: stray '\377' in program
jni/../../Classes/HelloWorldScene.cpp:1:1: error: stray '\376' in program
jni/../../Classes/HelloWorldScene.cpp:1:1: error: stray '#' in program
jni/../../Classes/HelloWorldScene.cpp:1:4: warning: null character(s) ignored [enabled by default]

jni/../../Classes/HelloWorldScene.cpp:1:6: warning: null character(s) ignored [enabled by default]

……

jni/../../Classes/HelloWorldScene.cpp:49:2: error: expected unqualified-id before '/' token
/cygdrive/e/cocos2d/Android-ndk-r9c-windows-x86/android-ndk-r9c/build/core/build-binary.mk:388: recipe for target 'obj/local/armeabi/objs/cocos2dcpp_shared/__/__/Classes/HelloWorldScene.o' failed
make: *** [obj/local/armeabi/objs/cocos2dcpp_shared/__/__/Classes/HelloWorldScene.o] Error 1
make: Leaving directory '/cygdrive/e/cocos2d/cocos2d-x-2.2.1/projects/GODS/proj.android'

在網上找了好幾下，沒能解決。

有的人說：可能是因為格式不是純粹的TXT格式子，而我用的編輯器沒能認出來。

也有的人說：這個錯誤一般是源代碼中含有一些隱藏的非ascii字符，可能原因在編輯器中使用的utf-8的格式保存源代碼中出現了中文的標點符號。

他們建議把東西copy到文本編輯器中，再copy回來試試

還有網友的建議是用UE（下載地址：http://lwr0312.blog.163.com/blog/static/48336807200931695730586/edit/）打開，用16進制編輯，刪除掉最前面多余的字節。

我對著操作，搞得暈乎乎，嗚嗚……沒有多余的字或者中文符號啊！并沒有解決問題。

后來終于看到一個帖子，里面的“gcc”幾個字，讓我看到了希望！！！下面附上地址：

http://wenku.baidu.com/link?url=_NgJPYtTUJ-WwLFEk38GgS_e5YdjYlltuc9E4oc4wvGHeGgk7OopTKzX66Epfg6MEYR1M7npZBnNkkwxwG7oRkZpxPgCIoVF6pTNYOYJ7YS

文中提及到“這是因為你的編譯器將文件編碼存為了UTF-8格式的,可是winavr作為gcc的編譯器是不認識這種格式的”，“將UTF-8改掉，改成US-ASIIC或者Chinese Simple(GB2312)都行，為什么Chinese Simple(GB2312)也行我也不知道，可能其他的也行只要不是UTF-8就行了”。

我這個原本是mac上的項目，移植到win的vs中時我把格式存為Unicode（當時錯了！如果當時就改為了ANSI就不會有這些報錯了！），現在從VS弄到安卓中（通過cygwin的gcc）要把格式另存為ANSI，然后就可以編譯通過了。

搞定，收工！終于，可以安心睡覺覺了！晚安，good night

不能手工 不能啊  這是別人的錯誤

ttps://loki-lib.svn.sourceforge.net/svnroot/loki-lib/trunk
把代碼檢出到本地，執行 make 后提示錯誤：
../../include/loki/StrongPtr.h:1: error: stray ‘/357’ in program
../../include/loki/StrongPtr.h:1: error: stray ‘/273’ in program
../../include/loki/StrongPtr.h:1: error: stray ‘/277’ in program
根據錯誤提示，應該是文件里存在非 ASCII 碼的字符，用 file 命令查看了一下 StrongPtr.h 的類型，發現是 Unicode text, UTF-8，而別的源文件則是 ASCII C++ program text，看來是 Loki 的某個維護者不小心把源文件存成 UTF-8 編碼的文件并在里面引入了非 ASCII 字符（UTF-8 編碼是一種兼容 ASCII 編碼的變長編碼方案）。上述的編譯錯誤中的字符是以 8 進制表示的，將其轉換成 16 進制后發現是”EF BB BF”，看著很眼熟——好像是 BOM(byte order mark) 控制字符，去維基百科里查一下 BOM 詞條，發現 UTF-8 文件的 BOM 果真是”EF BB BF”。而大多數 Windows 文件編輯器（包括記事本）在將文件保存為 Unicode 編碼時默認都會悄悄的在文件頭加上 BOM 字符且不會將其顯示出來（用 WinHex 之類的十六進制編輯器就打開則可以看到 BOM 字符），而 Linux 下卻沒這個默認的規矩，所以 Linux 下 g++ 不認 BOM 也是情理之中的。看來是 Loki 的維護者在 Windows 下修改代碼后不小心將 StrongPtr.h 存成 UTF-8 編碼文件，引入了肉眼看不到的 BOM 字符。后將 StrongPtr.h 另存為 ASCII 編碼的文件后果然編譯通過。
找到問題后去 Loki 的開發論壇上報告了這一問題，維護者之一的 syntheticpp 隨后修正了問題并在回帖里打趣的說：
Good to know “no BOMbs on Linux” ;-)
一語雙關的將 BOM 字符比作 BOMB（×××），呵呵，隱匿在文件里的 BOM 看不到摸不著，編譯時報告的錯誤也很不直白，大家在使用 Windows 下的文本編輯器編寫跨平臺代碼時要注意這個問題，建議使用 Notepad++ 這種可以顯式指定是否要加 BOM 字符的編輯器，以免挨炸。

• 頂

• 0

• 踩