Bug 463846 – dev-libs/gobject-introspection - dumper.py file for g-ir-scanner calls `gcc' directly

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Agostino Sarubbo 2013-03-30 11:44:52 UTC]

You receive this bug because this package does not respect my system's CC ( x86_64-pc-linux-gnu-gcc - /usr/bin/x86_64-pc-linux-gnu-gcc ) and calls directly gcc -/usr/bin/gcc
The possible solutions to fix this issue are:
1)Fix the buildsystem, if you can
2)inherit toolchain-funcs and use tc-export CC
3)inherit toolchain-funcs and use emake CC="$(tc-getCC)"


g-ir-scanner: compile: gcc -Wall -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=native -g0 -O2 -I./src -I./src -I./src/gdev -I./src/gdev 
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -c -o /tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectU71LMN/GUdev-1.0.o 
/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectU71LMN/GUdev-1.0.c

libtool: link: gcc -o /tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectU71LMN/.libs/GUdev-1.0 -march=native -g0 -O2 
/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectU71LMN/GUdev-1.0.o -pthread -Wl,--export-dynamic -pthread -Wl,--export-dynamic  -L. ./.libs/libgudev-1.0.so 
/tmp/portage/sys-fs/udev-200/work/systemd-200/.libs/libudev.so -ldl -lgio-2.0 -lgobject-2.0 -lgthread-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -pthread

[Comment 1 Samuli Suominen (RETIRED) 2013-03-30 11:51:00 UTC]

$ qfile /usr/lib/gobject-introspection/giscanner/dumper.py
dev-libs/gobject-introspection (/usr/lib64/gobject-introspection/giscanner/dumper.py)

/usr/lib/gobject-introspection/giscanner/dumper.py: self._compiler_cmd = os.environ.get('CC', 'gcc')

[Comment 2 Samuli Suominen (RETIRED) 2013-03-30 11:59:40 UTC]

Before adding `tc-export CC` from toolchain-funcs.eclass which fixes the issue the output was:

<log>
/var/log/portage/sys-fs:udev-200:20130330-115044.log:g-ir-scanner: compile: gcc -Wall -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -march=native -O2 -pipe -I./src -I./src -I./src/gdev -I./src/gdev -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -c -o /var/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectzkfHdy/GUdev-1.0.o /var/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectzkfHdy/GUdev-1.0.c
/var/log/portage/sys-fs:udev-200:20130330-115044.log:g-ir-scanner: link: /bin/sh ./libtool --mode=link --tag=CC gcc -o /var/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectzkfHdy/GUdev-1.0 -export-dynamic -march=native -O2 -pipe -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu /var/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectzkfHdy/GUdev-1.0.o -L. libgudev-1.0.la -lgio-2.0 -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lrt -lglib-2.0
/var/log/portage/sys-fs:udev-200:20130330-115044.log:libtool: link: gcc -o /var/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectzkfHdy/.libs/GUdev-1.0 -march=native -O2 -pipe -Wl,-O1 -Wl,--hash-style=gnu /var/tmp/portage/sys-fs/udev-200/work/systemd-200/tmp-introspectzkfHdy/GUdev-1.0.o -Wl,--export-dynamic -pthread -Wl,--export-dynamic  -Wl,--as-needed -L. ./.libs/libgudev-1.0.so /var/tmp/portage/sys-fs/udev-200/work/systemd-200/.libs/libudev.so -ldl -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lrt -lglib-2.0 -pthread
</log>

So everything using gobject-introspection, because of this dumper.py, needs a toolchain-funcs.eclass and tc-export CC

I've fixed this for >=sys-fs/udev-200 by adding the tc-export CC, but see:
http://qa-reports.gentoo.org/output/genrdeps/rindex/dev-libs/gobject-introspection
Who wants to handle a Tracker? :-(

[Comment 3 Samuli Suominen (RETIRED) 2013-03-30 12:05:54 UTC]

to clarify: gobject-introspection when used together with autotools does not respect autotools set CC but adds extra dependency of exporting CC also to the environment

[Comment 4 Gilles Dartiguelongue (RETIRED) 2013-03-31 23:57:04 UTC]

What if we fixed g-i instead ? :)

I really don't feel like exporting CC, AR and all those nice toolchain variables in every ebuild if that can be solved in a simpler way.

[Comment 5 Pacho Ramos 2013-04-07 09:53:36 UTC]

*** Bug 463862 has been marked as a duplicate of this bug. ***

[Comment 6 Gilles Dartiguelongue (RETIRED) 2013-05-10 21:51:19 UTC]

*** Bug 462974 has been marked as a duplicate of this bug. ***

[Comment 7 Gilles Dartiguelongue (RETIRED) 2013-05-10 22:20:41 UTC]

*** Bug 443126 has been marked as a duplicate of this bug. ***

[Comment 8 Gilles Dartiguelongue (RETIRED) 2013-05-10 22:20:48 UTC]

*** Bug 447612 has been marked as a duplicate of this bug. ***

[Comment 9 Samuli Suominen (RETIRED) 2013-05-27 17:10:49 UTC]

*** Bug 452798 has been marked as a duplicate of this bug. ***

[Comment 10 Alexandre Rostovtsev (RETIRED) 2013-06-24 13:05:14 UTC]

*** Bug 474534 has been marked as a duplicate of this bug. ***

[Comment 11 James Le Cuirot 2014-03-23 08:50:16 UTC]

I was thinking toolchain-funcs had a function for exporting all the variables but tc-env_build only exports the build system toolchain. Maybe a host system equivalent would be useful.

Having said that, I'm not sure what fixing this would actually achieve. It is not safe to run the gobject-introspection binaries when the target is a different architecture anyway. I have to wrap the calls with QEMU/proot in my own scripts.

[Comment 12 Jeroen Roovers (RETIRED) 2014-09-12 20:08:53 UTC]

*** Bug 522658 has been marked as a duplicate of this bug. ***

[Comment 13 Dainius Masiliūnas 2015-03-26 12:51:16 UTC]

*** Bug 544542 has been marked as a duplicate of this bug. ***

[Comment 14 Andreas Sturmlechner 2020-06-30 21:58:01 UTC]

*** Bug 717684 has been marked as a duplicate of this bug. ***