Created attachment 284123 [details] compressed build log g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC --silent gcc -o /var/tmp/portage/media-libs/babl-0.1.4/work/babl-0.1.4/babl/tmp-introspectazgUf2/Babl-0.1 -export-dynamic -march=native -O2 -pipe -ggdb -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -L. -lbabl-0.1 -pthread -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lbabl-0.1 -lm /var/tmp/portage/media-libs/babl-0.1.4/work/babl-0.1.4/babl/tmp-introspectazgUf2/Babl-0.1.o ERROR: can't resolve libraries to shared libraries: babl-0.1
Created attachment 284125 [details] my emerge --info
me too amd64 unstable nomultilib
Confirming. babl with USE=introspection builds successfully when babl (with or without introspection) is already installed systemwide, and fails if there is no babl previously installed. In other words, g-ir-scanner is scanning for the systemwide version of libbabl instead of the one in the build directory. This almost certainly indicates a bug in babl's makefiles.
This was fixed upstream by the following commit: http://git.gnome.org/browse/babl/commit/?id=d96973bc348b860b214e19f6cdefd24a78c745c6
(In reply to comment #4) > This was fixed upstream by the following commit: > http://git.gnome.org/browse/babl/commit/?id=d96973bc348b860b214e19f6cdefd24a78c745c6 That patch didn't fix the problem for me...
(In reply to comment #5) > (In reply to comment #4) > > This was fixed upstream by the following commit: > > http://git.gnome.org/browse/babl/commit/?id=d96973bc348b860b214e19f6cdefd24a78c745c6 > > That patch didn't fix the problem for me... Did you inherit autotools and add eautoreconf after the epatch?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > This was fixed upstream by the following commit: > > > http://git.gnome.org/browse/babl/commit/?id=d96973bc348b860b214e19f6cdefd24a78c745c6 > > > > That patch didn't fix the problem for me... > > Did you inherit autotools and add eautoreconf after the epatch? Of course I did. The patch definitely comes into effect (I can see it by the slightly different output when the error occurs) but still the same error(message) like without the patch comes up.
(In reply to comment #7) > The patch definitely comes into effect (I can see it by the slightly different > output when the error occurs) but still the same error(message) like without > the patch comes up. The patch definitely fixes the bug for me :/ Could you please attach the complete build log with the patch and with MAKEOPTS="V=1" ?
Created attachment 284535 [details] build.log Here you are. You can find the ebuild + patch in the poly-c overlay if you wanna test it.
(In reply to comment #9) > Created attachment 284535 [details] > build.log > > Here you are. You can find the ebuild + patch in the poly-c overlay if you > wanna test it. OK, I think I see the problem. Your log shows that you are linking libbabl-0.1 *after* starting to run g-ir-scanner on it. So obviously g-ir-scanner fails to find the library and errors out. Try MAKEOPTS=-j1
Created attachment 284541 [details] build.log I had a typo in the MAKEOPTS="V=1" variable so the previous build.log wasn't really verbose. Sorry for that. This one is a result of MAKEOPTS="-j1 V=1" emerge -1v babl which still fails the same way...
(In reply to comment #11) Still can't reproduce :/ With the same patch, same ebuild, same CFLAGS, same LDFLAGS, both with and without babl installed, on my machine babl with USE=introspection builds successfully. Do you have any version of babl previously installed, or a copy of libbabl-0.1.so floating in your /usr/local somewhere? What version of gobject-introspection are you using? (I have just successfully built babl with gobject-introspection-0.10.8 and 1.29.16.) Perhaps re-emerging gobject-introspection can help?
I've found the cause of my problem. The package fails with forced as-needed. See http://www.gentoo.org/proj/en/qa/asneeded.xml section "Forced --as-needed". As soon as I switch back to gcc without forced as-needed the package compiles without problems. Now I wonder if there still might be some problems with the package. From what I've experienced up to now forced as-needed shouldn't make a package fail.
*** Bug 356023 has been marked as a duplicate of this bug. ***
+*babl-0.1.4-r2 (28 Aug 2011) + + 28 Aug 2011; Justin Lecher <jlec@gentoo.org> -babl-0.1.4-r1.ebuild, + +babl-0.1.4-r2.ebuild, +files/babl-0.1.4-introspection.patch, metadata.xml: + Fix for build with introspection adapted from upstream patch, #380115 +
Appears to happen again with media-libs/babl-0.1.6, just with slightly different output... /usr/bin/g-ir-scanner -v --namespace Babl --nsversion=0.1 \ --add-include-path=. --add-include-path=. \ --library=libbabl-0.1.la \ --libtool="/bin/sh ../libtool" \ --output Babl-0.1.gir \ -DBABL_IS_BEING_COMPILED \ -I.. \ -I.. \ ./babl-macros.h ./babl-types.h ./babl.h \ ./babl-version.h \ ./babl.c ./babl-component.c ./babl-conversion.c ./babl-core.c ./babl-db.c ./babl-extension.c ./babl-fish-path.c ./babl-fish-reference.c ./babl-fish-simple.c ./babl-fish-stats.c ./babl-fish.c ./babl-format.c ./babl-hash-table.c ./babl-image.c ./babl-internal.c ./babl-introspect.c ./babl-list.c ./babl-memory.c ./babl-model.c ./babl-mutex.c ./babl-sampling.c ./babl-sanity.c ./babl-type.c ./babl-util.c ./babl-cpuaccel.c ./babl-version.c Must specify package names on the command line g-ir-scanner: compile: gcc -Wall -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -mmmx -msse -msse2 -msse3 -mssse3 -pipe -fomit-frame-pointer -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -I.. -I.. -c -o /var/tmp/portage/media-libs/babl-0.1.6/work/babl-0.1.6/babl/tmp-introspectoCBI3Y/Babl-0.1.o /var/tmp/portage/media-libs/babl-0.1.6/work/babl-0.1.6/babl/tmp-introspectoCBI3Y/Babl-0.1.c g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC gcc -o /var/tmp/portage/media-libs/babl-0.1.6/work/babl-0.1.6/babl/tmp-introspectoCBI3Y/Babl-0.1 -export-dynamic -O2 -D_FORTIFY_SOURCE=2 -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=core2 -mmmx -msse -msse2 -msse3 -mssse3 -pipe -fomit-frame-pointer -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wold-style-definition -L. libbabl-0.1.la -pthread -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 /var/tmp/portage/media-libs/babl-0.1.6/work/babl-0.1.6/babl/tmp-introspectoCBI3Y/Babl-0.1.o libtool: link: cannot find the library `libbabl-0.1.la' or unhandled argument `libbabl-0.1.la' linking of temporary binary failed: Command '['/bin/sh', '../libtool', '--mode=link', '--tag=CC', 'gcc', '-o', '/var/tmp/portage/media-libs/babl-0.1.6/work/babl-0.1.6/babl/tmp-introspectoCBI3Y/Babl-0.1', '-export-dynamic', '-O2', '-D_FORTIFY_SOURCE=2', '-march=core2', '-mcx16', '-msahf', '--param', 'l1-cache-size=32', '--param', 'l1-cache-line-size=64', '--param', 'l2-cache-size=4096', '-mtune=core2', '-mmmx', '-msse', '-msse2', '-msse3', '-mssse3', '-pipe', '-fomit-frame-pointer', '-Wall', '-Wdeclaration-after-statement', '-Wmissing-prototypes', '-Wmissing-declarations', '-Winit-self', '-Wpointer-arith', '-Wold-style-definition', '-L.', 'libbabl-0.1.la', '-pthread', '-lgio-2.0', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lglib-2.0', '/var/tmp/portage/media-libs/babl-0.1.6/work/babl-0.1.6/babl/tmp-introspectoCBI3Y/Babl-0.1.o']' returned non-zero exit status 1 make[3]: *** [Babl-0.1.gir] Error 1 make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/var/tmp/portage/media-libs/babl-0.1.6/work/babl-0.1.6/babl'
Recently hit this doing a rebuild pass, successfully built it as recently as Jan 7th , so something that has happened since then has triggered failing again. Here's the versions of things that are presently installed that are listed as dependencies which might be influencing the problem: F="=<category>/<name>-<version>{slots}:<slot>{else}{}\n" \ eix "-(" -e libtool -o -e vala -o -e pkgconfig -o -e automake -o -e autoconf -o -e gobject-introspection "-)" --format "<installedversions:F>" "-*" =dev-lang/vala-0.10.4-r1:0.10 =dev-lang/vala-0.12.1:0.12 =dev-lang/vala-0.14.2-r1:0.14 =dev-libs/gobject-introspection-1.30.0-r2 =dev-util/pkgconfig-0.26 =sys-devel/autoconf-2.13:2.1 =sys-devel/autoconf-2.68:2.5 =sys-devel/automake-1.4_p6-r1:1.4 =sys-devel/automake-1.5-r1:1.5 =sys-devel/automake-1.7.9-r2:1.7 =sys-devel/automake-1.8.5-r4:1.8 =sys-devel/automake-1.9.6-r3:1.9 =sys-devel/automake-1.10.3:1.10 =sys-devel/automake-1.11.3:1.11 =sys-devel/libtool-2.4.2:2 Complete Build log is here if its deemed useful: https://gist.github.com/2048094
(In reply to comment #17) > CFLAGS='-march=native -mtune=native -O3 -pipe --param l2-cache-size=6144 -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msahf -ffast-math -flto -ftree-loop-linear -ftree-loop-distribution -ftree-loop-im -floop-interchange -floop-strip-mine -floop-block' ಠ_ಠ Please rebuild your system with sane CFLAGS (something like "-march=native -O2 -pipe") and use the extreme and potentially unstable flags only for the small set of packages for which you ran tests and benchmarks and verified that the flags don't break anything and make a non-negligible performance difference.
(In reply to comment #18) > (In reply to comment #17) > > CFLAGS='-march=native -mtune=native -O3 -pipe --param l2-cache-size=6144 -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msahf -ffast-math -flto -ftree-loop-linear -ftree-loop-distribution -ftree-loop-im -floop-interchange -floop-strip-mine -floop-block' > > ಠ_ಠ > > Please rebuild your system with sane CFLAGS (something like "-march=native > -O2 -pipe") and use the extreme and potentially unstable flags only for the > small set of packages for which you ran tests and benchmarks and verified > that the flags don't break anything and make a non-negligible performance > difference. Yes, I know those flags are insane ;). I'm *trying* to break things. I have a large blacklist file I'm building where I hole-punch things that are broken with insane flags. And yeah, I /do/ run tests too =). Though with regard to this package, the flags themselves don't seem to be evident the cause. grep "" /var/db/pkg/media-libs/babl-0.1.6/*FLAGS /var/db/pkg/media-libs/babl-0.1.6/CFLAGS:-march=native -mtune=native -O3 -pipe --param l2-cache-size=6144 -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msahf -ffast-math -flto -ftree-loop-linear -ftree-loop-distribution -ftree-loop-im -floop-interchange -floop-strip-mine -floop-block /var/db/pkg/media-libs/babl-0.1.6/CXXFLAGS:-march=native -mtune=native -O3 -pipe --param l2-cache-size=6144 -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msahf -ffast-math -flto -ftree-loop-linear -ftree-loop-distribution -ftree-loop-im -floop-interchange -floop-strip-mine -floop-block /var/db/pkg/media-libs/babl-0.1.6/LDFLAGS:-Wl,-O1 -Wl,-z,combreloc -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=both Previously that insanity worked enough to compile. And note, the error is identical to above listed Chris Slycords , who had sane C*Flags.
