After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757934 - g-ir-scanner should not use system-provided CFLAGS
g-ir-scanner should not use system-provided CFLAGS
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-11-11 10:17 UTC by Thomas Haller
Modified: 2018-02-08 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
giscanner: Disable warnings arising from -D_FORTIFY_SOURCE -O0 (1.65 KB, patch)
2016-01-30 14:47 UTC, Philip Withnall
committed Details | Review

Description Thomas Haller 2015-11-11 10:17:18 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):

  export CFLAGS='-O0'
  ./autogen.sh
  make


this will call g-ir-scanner via Makefile.introspection like:


CPPFLAGS="" \
CFLAGS="[] -O0 [...]" \
LDFLAGS="[...]" CC="" \
/usr/bin/g-ir-scanner [...]


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",),)
> /usr/lib64/python2.7/distutils/unixccompiler.py(132)_compile()
-> raise CompileError, msg
(Pdb) bt
  /usr/bin/g-ir-scanner(58)<module>()
-> sys.exit(scanner_main(sys.argv))
  /usr/lib64/gobject-introspection/giscanner/scannermain.py(530)scanner_main()
-> shlibs = create_binary(transformer, options, args)
  /usr/lib64/gobject-introspection/giscanner/scannermain.py(412)create_binary()
-> gdump_parser.get_error_quark_functions())
  /usr/lib64/gobject-introspection/giscanner/dumper.py(321)compile_introspection_binary()
-> return dc.run()
  /usr/lib64/gobject-introspection/giscanner/dumper.py(162)run()
-> introspection_obj = self._compile(c_path)
  /usr/lib64/gobject-introspection/giscanner/dumper.py(201)_compile()
-> self._options.init_sections)
  /usr/lib64/gobject-introspection/giscanner/ccompiler.py(239)compile()
-> source_str.rfind(os.sep)])
  /usr/lib64/python2.7/distutils/ccompiler.py(574)compile()
-> self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
> /usr/lib64/python2.7/distutils/unixccompiler.py(132)_compile()
-> 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
Comment 1 Philip Withnall 2016-01-30 14:47:26 UTC
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,
unfortunately.
Comment 2 Colin Walters 2016-01-30 16:24:31 UTC
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.
Comment 3 Philip Withnall 2016-01-31 08:56:06 UTC
(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. :-(
Comment 4 Philip Withnall 2016-01-31 08:57:03 UTC
Attachment 320077 [details] pushed as 0ff7ca9 - giscanner: Disable warnings arising from -D_FORTIFY_SOURCE -O0
Comment 5 Ting-Wei Lan 2016-02-01 07:35:51 UTC
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):
  • File "/home/lantw44/gnome/devinstall/bin/g-ir-scanner", line 66 in <module>
    sys.exit(scanner_main(sys.argv))
  • File "/home/lantw44/gnome/devinstall/lib/gobject-introspection/giscanner/scannermain.py", line 544 in scanner_main
    shlibs = create_binary(transformer, options, args)
  • File "/home/lantw44/gnome/devinstall/lib/gobject-introspection/giscanner/scannermain.py", line 419 in create_binary
    gdump_parser.get_error_quark_functions())
  • File "/home/lantw44/gnome/devinstall/lib/gobject-introspection/giscanner/dumper.py", line 328 in compile_introspection_binary
    return dc.run()
  • File "/home/lantw44/gnome/devinstall/lib/gobject-introspection/giscanner/dumper.py", line 167 in run
    introspection_obj = self._compile(c_path)
  • File "/home/lantw44/gnome/devinstall/lib/gobject-introspection/giscanner/dumper.py", line 207 in _compile
    self._options.init_sections)
  • File "/home/lantw44/gnome/devinstall/lib/gobject-introspection/giscanner/ccompiler.py", line 246 in compile
    source_str.rfind(os.sep)]))
  • File "/usr/local/lib/python2.7/distutils/ccompiler.py", line 574 in compile
    self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
  • File "/usr/local/lib/python2.7/distutils/unixccompiler.py", line 122 in _compile
    raise CompileError, msg
distutils.errors.CompileError: command 'clang' failed with exit status 1

Comment 6 Philip Withnall 2016-02-06 17:57:11 UTC
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"
Comment 7 Colin Walters 2016-02-11 14:09:58 UTC
(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.
Comment 8 Matthias Clasen 2016-03-01 22:55:13 UTC
doesn't seem like target list material to me, dropping
Comment 9 Mikhail Zabaluev 2018-01-10 06:32:09 UTC
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:

>>> distutils.sysconfig.get_config_vars('CFLAGS')
['-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.
Comment 10 GNOME Infrastructure Team 2018-02-08 12:40:04 UTC
-- 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.