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 774342 - gcab does not build with make -jN
gcab does not build with make -jN
Status: RESOLVED FIXED
Product: msitools
Classification: Other
Component: gcab
git
Other Mac OS
: Normal normal
: 1.0
Assigned To: msitools maintainer(s)
msitools maintainer(s)
: 785271 (view as bug list)
Depends on:
Blocks: 774453
 
 
Reported: 2016-11-13 03:51 UTC by Philip Chimento
Modified: 2017-07-24 09:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
build-sys: Fix dependency on generated .h files (801 bytes, patch)
2016-11-13 03:51 UTC, Philip Chimento
none Details | Review
build-sys: Fix dependency on generated .h files (818 bytes, patch)
2016-11-13 22:12 UTC, Philip Chimento
none Details | Review
build-sys: Fix dependency on generated .h file (814 bytes, patch)
2016-11-27 20:41 UTC, Philip Chimento
committed Details | Review

Description Philip Chimento 2016-11-13 03:51:04 UTC
Build failure:
      CC       libgcab/libgcab_1_0_la-cabinet.lo
    /Users/fliep/Documents/Coding/gnome/gcab/libgcab/gcab-folder.c:114:28: error: 
          use of undeclared identifier 'GCAB_TYPE_COMPRESSION'
                               GCAB_TYPE_COMPRESSION, 0,
                               ^
    26 warnings and 1 error generated.

It looks like this is a race between the gcab-enums.h file being written and being included in gcab-folder.c. The .c files should have a dependency on gcab-enums.h. Adding the .h files to the SOURCES variable should do the trick.
Comment 1 Philip Chimento 2016-11-13 03:51:55 UTC
Created attachment 339732 [details] [review]
build-sys: Fix dependency on generated .h files

Otherwise there is a race between gcab-enums.h being generated and
included in other compilations.
Comment 2 Philip Chimento 2016-11-13 22:11:43 UTC
Hmm, that didn't actually solve the race. Here's a different patch that I think does solve it.
Comment 3 Philip Chimento 2016-11-13 22:12:46 UTC
Created attachment 339771 [details] [review]
build-sys: Fix dependency on generated .h files

Otherwise there is a race between gcab-enums.h being generated and
included in other compilations.
Comment 4 Marc-Andre Lureau 2016-11-19 14:59:55 UTC
Review of attachment 339771 [details] [review]:

::: Makefile.am
@@ +60,3 @@
 	$(NULL)
 libgcab_1_0_la_DEPENDENCIES = libgcab.syms
+libgcab_1_0_la_SOURCES: libgcab/gcab-enums.h

I don't think that's a valid target.
Comment 5 Marc-Andre Lureau 2016-11-19 15:02:46 UTC
the error you reported doesn't look like a race of missing generated file.

automake does generate BUILT_SOURCES before any other targets, so it should be race-free. Furthermore, I can reliably

rm libgcab/gcab-enums.{c,h}
make -j

without build issue.

Do you have a reproducer?

thanks
Comment 6 Philip Chimento 2016-11-27 20:41:19 UTC
(In reply to Marc-Andre Lureau from comment #4)
> Review of attachment 339771 [details] [review] [review]:
> 
> ::: Makefile.am
> @@ +60,3 @@
>  	$(NULL)
>  libgcab_1_0_la_DEPENDENCIES = libgcab.syms
> +libgcab_1_0_la_SOURCES: libgcab/gcab-enums.h
> 
> I don't think that's a valid target.

Yup, you are right, I meant $(libgcab_1_0_la_SOURCES): libgcab/gcab-enums.h
But I don't think that's correct either, as it introduces circular dependencies. Since gcab-priv.h is the only file that includes gcab-enums.h, I'll attach a patch that just makes that dependency explicit.

> Do you have a reproducer?

Consistently, every time I wipe my build directory (jhbuild uninstall gcab; jhbuild cleanone gcab; rm -rf ~/.cache/jhbuild/build/gcab) and rebuild, I get this failure: https://gist.github.com/ptomato/397ea9bb17646dd36d08fa182ba759f8

If I rerun make, then it continues on as if nothing happened. It doesn't happen in the first place if I use make -j1. To me, that suggests a race caused by a missing dependency.

Looking at the error log, automake does indeed generate BUILT_SOURCES first, but as you can see, it starts the build of gcab-folder.c (which requires gcab-enums.h) at the same time as the BUILT_SOURCES, in the same batch of 5 jobs, so it's still not ready before gcab-folder is compiling.
Comment 7 Philip Chimento 2016-11-27 20:41:51 UTC
Created attachment 340859 [details] [review]
build-sys: Fix dependency on generated .h file

Otherwise there is a race between gcab-enums.h being generated and
included in other compilations.
Comment 8 Marc-Andre Lureau 2016-11-28 05:07:41 UTC
Review of attachment 340859 [details] [review]:

::: Makefile.am
@@ +60,3 @@
 	$(NULL)
 libgcab_1_0_la_DEPENDENCIES = libgcab.syms
+libgcab/gcab-priv.h: libgcab/gcab-enums.h

looks good, ack
Comment 9 Philip Chimento 2016-11-29 02:32:48 UTC
Attachment 340859 [details] pushed as 199138f - build-sys: Fix dependency on generated .h file
Comment 10 Michael Catanzaro 2017-07-22 17:20:16 UTC
*** Bug 785271 has been marked as a duplicate of this bug. ***
Comment 11 Michael Catanzaro 2017-07-22 17:21:53 UTC
This is still happening unfortunately. See bug #785271.
Comment 12 Philip Chimento 2017-07-22 17:50:55 UTC
Probably it has to list out gcab-enums.h as a dependency of every file that includes it, then. I understand there was recently a Python 3 port of glib-mkenums, maybe that exposed this?
Comment 13 Marc-Andre Lureau 2017-07-22 18:11:47 UTC
yep, that might be related to the python port


argh

$ glib-mkenums --identifier-prefix GCab --symbol-prefix gcab --template libgcab/gcab-enums.h.etemplate libgcab/gcab-folder.h libgcab/gcab-file.h > libgcab/gcab-enums.h
Traceback (most recent call last):
  • File "/usr/local/bin/glib-mkenums", line 395 in <module>
    write_output(prod)
  • File "/usr/local/bin/glib-mkenums", line 74 in write_output
    print(output, file=output_stream)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 34: ordinal not in range(128)

I bet this is the 'é' in my name ;)
Comment 14 Marc-Andre Lureau 2017-07-24 09:27:20 UTC
see bug 785113
Comment 15 Marc-Andre Lureau 2017-07-24 09:27:33 UTC
(it has the fix pending for commit)