cc1plus：警告：命令行选项“ -Wstrict-prototypes”对Ada / C / ObjC有效，但对C ++无效

Question

我正在构建用于Python的C ++扩展。我看到在编译过程中生成此警告-类型为：

python setup.py build_ext -i

是什么原因引起的，如何解决？

顺便说一句，这是我的安装文件的副本：

#!/usr/bin/env python

    """
    setup.py file for SWIG example
    """

    from distutils.core import setup, Extension


    example_module = Extension('_foolib',
                               sources=['example_wrap.cxx', 
                                        '../wrapper++/src/Foo.cpp'
                                       ],
                               libraries=["foopp"]
                               )

    setup (name = 'foolib',
           version = '0.1',
           author      = "Me, Myself and I",
           description = """Example""",
           ext_modules = [example_module],
           py_modules = ["example"],
           )

我在Ubuntu上使用gcc 4.4.3

Answer 1

我可以回答部分问题，为什么会收到消息。

在构建过程中，有些事情是使用选项调用C ++源文件上的gcc -Wstrict- prototypes。对于C和Objective-C，这会使编译器警告未声明参数类型的旧式函数声明。

对于C ++，此选项没有任何意义。这种语言甚至都不允许这样的声明（原型是强制性的）。

（我不知道为什么消息中提到Ada；-Wstrict-prototypes对Ada而言，其含义甚至比对C
++而言没有多大意义。但这并不是什么大问题，但我已提交了此错误报告，从2015年12月6日起标记为已解决/已修复。
）

解决方案应该是-Wstrict-prototypes从gcc调用中删除该选项。但是由于您不是直接调用gcc，所以很难知道该怎么做。

setup.py手动创建虚拟example_wrap.cxx文件后，我可以使用来重现警告：

% python setup.py build_ext -i
running build_ext
building '_foolib' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c example_wrap.cxx -o build/temp.linux-i686-2.7/example_wrap.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
...

因此，这可能是Python的一个小错误build_ext。

但是由于这只是警告，而不是致命错误，我想您可以放心地忽略它。gcc警告无意义的选项，但随后它会忽略它。

编辑 ：

查看Python-2.7.2的源代码，这部分configure.in可能是罪魁祸首：

case $GCC in
yes)
    if test "$CC" != 'g++' ; then
        STRICT_PROTO="-Wstrict-prototypes"
    fi

（我假设是在使用时调用的build_ext。）

-Wstrict-prototypes仅当 未 以g++-方式调用编译器时，它才会打开该选项，但在您的情况下，它将使用gcc命令来编译C
源代码。而且 Lib/distutils/command/build_ext.py， build_extension()在调用 self.compiler.compile()时，不必仅仅注意源文件的语言 self.compiler.link_shared_object()。（这似乎很奇怪；对于gcc以外的编译器，您不一定能够使用相同的命令来编译C和C
－g++即使不进行链接，无论如何仍要使用该命令。）

更新：提交了一个Python错误报告：https :
//bugs.python.org/issue9031，并作为以下内容的副本进行了关闭：https
:
//bugs.python.org/issue1222585，在我撰写本文时仍处于打开状态。

但是正如我所说，这只是一个警告，您可以放心地忽略它。也许Python维护人员可以使用以上信息在将来的版本中解决该问题。