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
$ 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')
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? :-(
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
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.
*** Bug 463862 has been marked as a duplicate of this bug. ***
*** Bug 462974 has been marked as a duplicate of this bug. ***
*** Bug 443126 has been marked as a duplicate of this bug. ***
*** Bug 447612 has been marked as a duplicate of this bug. ***
*** Bug 452798 has been marked as a duplicate of this bug. ***
*** Bug 474534 has been marked as a duplicate of this bug. ***
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.
*** Bug 522658 has been marked as a duplicate of this bug. ***
*** Bug 544542 has been marked as a duplicate of this bug. ***
*** Bug 717684 has been marked as a duplicate of this bug. ***
