error: stray '377' in program

Posted 2020-08-22

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

• 踩