如何解决 GCC“错误:来自“SourceLocation*”的转换?到“int”失去精度”编译cmockery.c时出错?
我需要使用 Cmockery 将单元测试添加到用作手工制作的现有构建环境中生成文件。所以我需要弄清楚如何构建 cmockery.c (没有 automake)。
当我运行时:
g++ -DHAVE_CONFIG_H -DPIC -I ../cmockery-0.1.2 -I /usr/include/malloc -c ../cmockery-0.1.2/cmockery.c -o obj/cmockery.o
我得到一长串这样的错误:
../cmockery-0.1.2/cmockery.c: In function ‘void initialize_source_location(SourceLocation*)’:
../cmockery-0.1.2/cmockery.c:248: error: cast from ‘SourceLocation*’ to ‘int’ loses precision
Here arelines 247:248 of cmockery.c:
static void initialize_source_location(SourceLocation * const location) {
assert_true(location);
assert_true
is Define on line 154 of cmockery.h:
#define assert_true(c) _assert_true((int)(c), #c, __FILE__, __LINE__)
所以问题(作为错误状态)是 GCC 不喜欢从 'SourceLocation*' 到 'int' 的转换。
我可以使用 ./configure
和 make
构建 Cmockery(在 Linux 上,以及 在 Mac OS X 上(如果我先导出 CFLAGS=-I/usr/include/malloc
),没有任何错误。我尝试在运行 make
时查看编译 cmockery.c 的命令行(在 ./configure
之后):
gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Isrc/google -I/usr/include/malloc -MT libcmockery_la-cmockery.lo -MD -MP -MF .deps/libcmockery_la-cmockery.Tpo -c src/cmockery.c -fno-common -DPIC -o .libs/libcmockery_la-cmockery.o
...但我没有看到任何可能解决此错误的选项。
在“错误:从 'void*' 到 'int' 的转换丢失精度”,我发现我可以将 cmockery.h 中的 (int)
更改为 (intptr_t)
。我已经确认这是有效的。但由于我可以使用 ./configure
和 make
构建 Cmockery,因此必须有一种方法可以在不修改源代码的情况下构建它。
I need to add unit tests using Cmockery to an existing build environment that uses as hand-crafted Makefile. So I need to figure out how to build cmockery.c (without automake).
When I run:
g++ -DHAVE_CONFIG_H -DPIC -I ../cmockery-0.1.2 -I /usr/include/malloc -c ../cmockery-0.1.2/cmockery.c -o obj/cmockery.o
I get a long list of errors like this:
../cmockery-0.1.2/cmockery.c: In function ‘void initialize_source_location(SourceLocation*)’:
../cmockery-0.1.2/cmockery.c:248: error: cast from ‘SourceLocation*’ to ‘int’ loses precision
Here are lines 247:248 of cmockery.c:
static void initialize_source_location(SourceLocation * const location) {
assert_true(location);
assert_true
is defined on line 154 of cmockery.h:
#define assert_true(c) _assert_true((int)(c), #c, __FILE__, __LINE__)
So the problem (as the error states) is GCC doesn't like the cast from ‘SourceLocation*’ to ‘int’.
I can build Cmockery using ./configure
and make
(on Linux, and on Mac OS X if I export CFLAGS=-I/usr/include/malloc
first), without any errors. I've tried looking at the command-line that compiles cmockery.c when I run make
(after ./configure
):
gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -Isrc/google -I/usr/include/malloc -MT libcmockery_la-cmockery.lo -MD -MP -MF .deps/libcmockery_la-cmockery.Tpo -c src/cmockery.c -fno-common -DPIC -o .libs/libcmockery_la-cmockery.o
...but I don't see any options that might work around this error.
In "error: cast from 'void*' to 'int' loses precision", I see I could change (int)
in cmockery.h to (intptr_t)
. And I've confirmed that works. But since I can build Cmockery with ./configure
and make
, there must be a way to get it to build without modifying the source.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在我的系统上使用
gcc
而不是g++
会将该错误变成我的系统(Mandriva Linux 2010.1 64 位)上的警告,并允许编译完成:我觉得有必要然而,需要指出的是,当我看到一大堆关于相对常见的平台(Linux 64 位/GCC,我想还有其他平台)的警告时,我通常会保持警惕。使用
-m32
选项强制编译为 32 位目标文件不会产生任何警告,因此可以推测按原样使用的源代码可能不是 64 位干净的。无论您是否使用自动工具,都会发生这种情况。我不知道有问题的项目,所以它很可能没问题,但无论如何都要谨慎使用...
编辑:
根据 this 回答 OP 在 cmockery 邮件列表中提出的问题,当前版本目前还不是 64 位干净的。似乎错误/警告的存在是有充分理由的......
Using
gcc
instead ofg++
on my system turns that error into a warning on my system (Mandriva Linux 2010.1 64-bit) and allows the compilation to complete:I feel the need to point out, however, that I am generally wary when I see a whole horde of warnings on what is a relatively common platform (Linux 64-bit/GCC and I would presume others). Using the
-m32
option to force compilation to a 32-bit object file does not produce any warnings, so one could presume that the source code used as-is is may not be 64-bit clean. This happens whether you use the autotools or not.I don't know the project in question, so it might very well be OK, but in any case use with caution...
EDIT:
According to this answer to the OP's question to the cmockery mailing list, the current release is not 64-bit clean at this time. It seems that the errors/warnings were there for a good reason...