GNOME Bugzilla – Bug 726008
giscanner emits error spew, causes gcr build to fail
Last modified: 2015-02-07 17:01:39 UTC
I haven't been able to build gcr with jhbuild recently. It fails with: VAPIGEN gcr-ui-3.vapi GICOMP GcrUi-3.gir GcrUi-3.gir:1586.5-1588.58: error: `Gcr' already contains a definition for `UNLOCK_OPTION_IDLE' gcr-3.vapi:430.2-430.40: note: previous definition of `UNLOCK_OPTION_IDLE' was here make[2]: *** [gcr-ui-3.vapi] Error 1 make[2]: *** Waiting for unfinished jobs.... rm ui/gcr-viewer.desktop.in ui/gcr-prompter.desktop.in make[2]: Leaving directory `/home/mcatanzaro/jhbuild/src/gcr' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mcatanzaro/jhbuild/src/gcr' make: *** [all] Error 2
Which OS are you using? Can you reproduce this with a clean jhbuild? Could you include complete verbose output of the build?
Also, it might be helpful if you could post the generated GcrUi-3.gir, or just paste the method/constructor/whatever containing lines 1586-1588.
Created attachment 271672 [details] clean jhbuild log Using jhbuild on Fedora 20
Created attachment 271673 [details] Gcr-3.gir
Created attachment 271674 [details] Gcr-3.broken.gir Judging from the Makefile.am, this is an expected intermediate result in the build process, but I'm attaching it in case it helps.
Created attachment 271675 [details] gcr-3.vapi
Created attachment 271676 [details] The file that was actually requested Looks like I just attached everything except the file that was actually requested. Almost didn't notice.
GcrUi-3.gir lines 1586-1591 are: <constant name="UNLOCK_OPTION_IDLE" value="idle" c:type="GCR_UNLOCK_OPTION_IDLE"> <doc xml:space="preserve">Option name for caching unlock for a certain amount of idle time.</doc> <type name="utf8" c:type="gchar*"/> </constant> Which is a duplicate entry from Gcr-3. So in this case vapigen is really doing the right thing and notifying you about a problem in the gir—the question is why is that in the GcrUi-3 GIR. The "clean jhbuild log" attachment is pretty crazy. I'm on F20 too (x86_64, even), and it definitely doesn't spew those errors starting on line 521...
Oh really? I assumed everybody was getting those errors from gir. It's been doing that for about three months now (for every program that uses gir). My "clean jhbuild log" means I wiped out the gcr directory at the start of the build, but the last time I set up a temporary jhbuild environment on Ubuntu a month or two ago (using a live CD, so it was as clean as you could possibly get), I got the same style of errors from gir. Well, if you're not seeing those, I guess they're probably the cause.
cbafcdb323307fd6bb5e48b44167fd995dc933a1 is the first bad commit commit cbafcdb323307fd6bb5e48b44167fd995dc933a1 Author: Ryan Lortie <desrt@desrt.ca> Date: Sun Dec 8 11:48:08 2013 -0500 scanner: make sure we pass CFLAGS to cpp When doing the source scanning in giscanner, make sure we pass the user's CFLAGS environment variable to the compiler, as we do for the dumper. https://bugzilla.gnome.org/show_bug.cgi?id=720063 Hm... well this explains why it was only failing for me; I set my CFLAGS in my jhbuildrc. Modifying CFLAGS in any way (including leaving it blank), as demonstrated in the default sample.jhbuildrc file, is enough to cause the error spew. # this breaks giscanner os.environ['CFLAGS'] = '-Wno-error=deprecated-declarations -O0 -ggdb3' # this also breaks giscanner os.environ['CFLAGS'] = '' If I omit the line completely, it works. If I attempt to build without jhbuild and with empty CFLAGS set, it fails.
Ryan, can you take a look at this?
I'm facing this issue. Blocks me from building gnome-shell in jhbuild. :(
Pretty sure this is actually a dup of bug 720504 ?
Of course! *** This bug has been marked as a duplicate of bug 720504 ***
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]