GNOME Bugzilla – Bug 757934
g-ir-scanner should not use system-provided CFLAGS
Last modified: 2018-02-08 12:40:04 UTC
g-ir-scanner invokes the CC compiler with both the CFLAGS and the flags from the python installation. These flags can conflict and g-ir-scanner should only rely on the externally passed in CFLAGS.
This is easily reproducible when building NetworkManager from source (on Fedora23):
this will call g-ir-scanner via Makefile.introspection like:
CFLAGS=" -O0 [...]" \
LDFLAGS="[...]" CC="" \
g-ir-scanner then will eventually call:
gcc -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -Wall -std=gnu89 -Werror -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement -Wformat-security -Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -fno-strict-aliasing -Wno-unused-but-set-variable -Wundef -Wimplicit-function-declaration -Wpointer-arith -Winit-self -Wmissing-include-dirs -Wno-pragmas -O0 -DNMTST_TEST_QUICK=TRUE -Warray-bounds -Wunused-value -fPIC -DNMTST_TEST_QUICK=TRUE -I/usr/include/gudev-1.0 -I/usr/include/gio-unix-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gudev-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -c /data/src/NetworkManager/libnm/tmp-introspectQKWvRm/NM-1.0.c -o tmp-introspectQKWvRm/data/src/NetworkManager/libnm/tmp-introspectQKWvRm/NM-1.0.o -Wno-deprecated-declarations -pthread
Note that this effectively specifies "-D_FORTIFY_SOURCE=2 ... -O0", which leads to a compiler error:
/usr/include/features.h:328:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
cc1: all warnings being treated as errors
Caught exception: <class 'distutils.errors.CompileError'> CompileError(DistutilsExecError("command 'gcc' failed with exit status 1",),)
-> raise CompileError, msg
-> shlibs = create_binary(transformer, options, args)
-> return dc.run()
-> introspection_obj = self._compile(c_path)
-> self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
-> raise CompileError, msg
But the problem is, that g-ir-scanner uses the CFLAGS from ccompiler.py which are are incompatible with what we want to specify and there is no way to turn that off.
Currently, we worked around this via: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f6272144e98c00db18cf6708aceab96e6e7b1705
Created attachment 320077 [details] [review]
giscanner: Disable warnings arising from -D_FORTIFY_SOURCE -O0
Using distutils.ccompiler means that we are forced to use the CFLAGS
from the system’s Python installation, which may contain
-D_FORTIFY_SOURCE. The user’s environment-provided CFLAGS may contain
-O0 (because they are a developer). These two flags cause a warning when
used together. Silence that warning by passing -Wno-cpp to disable
warnings from #warning preprocessor statements in the generated C code.
It doesn’t seem to be possible to selectively undefine _FORTIFY_SOURCE
or to stop using the compiler flags from distutils.sysconfig,
Review of attachment 320077 [details] [review]:
This is really a distutils bug, and has bit me elsewhere - it totally breaks when distutils was built with a cross-compiler and you want to use it natively for example.
Anyways...it's quite unfortunate to turn off all warnings for a *non-default* case (using jhbuild). It means "real" builds won't get any C preprocessor warnings.
I can't think of a fix that doesn't involve patching distutils though.
(In reply to Colin Walters from comment #2)
> Review of attachment 320077 [details] [review] [review]:
> This is really a distutils bug, and has bit me elsewhere - it totally breaks
> when distutils was built with a cross-compiler and you want to use it
> natively for example.
> Anyways...it's quite unfortunate to turn off all warnings for a
> *non-default* case (using jhbuild). It means "real" builds won't get any C
> preprocessor warnings.
I don’t think it’s quite as bad as that, since this only affects compilation of the generated code for the GIR, which in practice means the set of #warning directives in that code and the headers it pulls in. I don’t think this will result in any legitimate warnings being squashed (unless you know of some which will?).
But yes, it’s not a great fix. :-(
Attachment 320077 [details] pushed as 0ff7ca9 - giscanner: Disable warnings arising from -D_FORTIFY_SOURCE -O0
This breaks ibus-anthy build when using clang because clang doesn't support -Wno-cpp.
error: unknown warning option '-Wno-cpp' [-Werror,-Wunknown-warning-option]
Traceback (most recent call last):
shlibs = create_binary(transformer, options, args)
introspection_obj = self._compile(c_path)
self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
raise CompileError, msg
Hmm, that’s a pain. I’ve reverted it until I can come up with a better solution. Do you have any suggestions?
c2f0c7b Revert "giscanner: Disable warnings arising from -D_FORTIFY_SOURCE -O0"
(In reply to Philip Withnall from comment #6)
> Hmm, that’s a pain. I’ve reverted it until I can come up with a better
> solution. Do you have any suggestions?
The only fix I can think of is adding an API to distutils to turn off the CFLAGS inheritance from its build.
doesn't seem like target list material to me, dropping
This also bites on Mac OS X, where 'make check' in gobject-introspection is broken for me, because the python 3 installation adds architecture options to CFLAGS that trigger a static assert in glib headers:
['-fno-strict-aliasing -Wsign-compare -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -arch i386 -arch x86_64 -g']
I'm blaming the call to distutils.sysconfig.customize_compiler in ccompiler.py.
While convenient to get a working preprocessor configuration and apply the overrides from the environment, this defaults to Python's build configuration which may be different from glib.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/150.