1160798 - |mach build| fails with --disable-compile-environment on Mac OS X: "No such file or directory: u'$OBJDIR/modules/libmar/tool/signmar'

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Nick Alexander :nalexander [he/him]]

On Mac OS X, with --disable-compile-environment, I see failures with missing signmar.  Presumably this is a host binary (like mobile/android's host/szip) that we need to provide or work-around with DCE.

$ mach build

...
 1:04.92 Exporting extension to source/test/addons/unsafe-content-script.xpi.
 1:06.68 Traceback (most recent call last):
 1:06.68   File "/Users/nalexander/Mozilla/gecko/config/nsinstall.py", line 181, in <module>
 1:06.68     sys.exit(_nsinstall_internal(argv[1:]))
 1:06.68   File "/Users/nalexander/Mozilla/gecko/config/nsinstall.py", line 146, in _nsinstall_internal
 1:06.68     copy_all_entries(args, target)
 1:06.68   File "/Users/nalexander/Mozilla/gecko/config/nsinstall.py", line 106, in copy_all_entries
 1:06.68     handleTarget(e, dest)
 1:06.68   File "/Users/nalexander/Mozilla/gecko/config/nsinstall.py", line 136, in handleTarget
 1:06.68     shutil.copy(srcpath, targetpath)
 1:06.68   File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 119, in copy
 1:06.68     copyfile(src, dst)
 1:06.68   File "/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py", line 82, in copyfile
 1:06.68     with open(src, 'rb') as fsrc:
 1:06.68 IOError: [Errno 2] No such file or directory: u'/Users/nalexander/Mozilla/gecko/objdir-desktop/modules/libmar/tool/signmar'
 1:06.68 make[5]: *** [libs] Error 1
 1:06.68 make[4]: *** [modules/libmar/tests/libs] Error 2
 1:06.68 make[3]: *** [libs] Error 2
 1:06.68 make[2]: *** [default] Error 2
 1:06.68 make[1]: *** [realbuild] Error 2
 1:06.68 make: *** [build] Error 2
 1:06.73 0 compiler warnings present.

Comment 1

[:Gijs (he/him)]

This also happens on Windows.

Comment 2

[:Gijs (he/him)]

It seems confvars.sh forces MOZ_ENABLE_SIGNMAR on, but all the mozconfig files for debug/nightly builds have ac_add_option --enable-signmar, which does the same.

Mike, can we just get rid of that line in confvars.sh?

(having done that locally, it seems --disable-compile-environment builds next fail in the updater...)

Comment 3

[Mike Hommey [:glandium]]

That's a question for the person who added it.

Comment 4

[Brian R. Bondy [:bbondy]]

It's host but it's good to have the tests run for it. I don't know about --disable-compile-environment but feel free to adjust as you see fit.  verifymar is the option for mar verifications which is the most important one.

Comment 5

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1160798 - don't enable signmar in convars.sh if we don't have a compile environment, r?glandium

Bug 1160798 - don't enable signmar in convars.sh if we don't have a compile environment, r?glandium

Comment 6

[Mike Hommey [:glandium]]

Comment on attachment 8624337 [details]
MozReview Request: Bug 1160798 - don't enable signmar in convars.sh if we don't have a compile environment, r?glandium

https://reviewboard.mozilla.org/r/11675/#review10183

::: browser/confvars.sh:29
(Diff revision 1)
> +if test "$COMPILE_ENVIRONMENT"; then

This would be better done in configure.in, because there's also --enable-signmar that can be passed manually, and that should also be disabled when building without a compile environment.

Comment 7

[Nick Alexander :nalexander [he/him]]

Attachment: MozReview Request: Bug 1160798 - Work around --disable-compile-environment issues on Mac OS X. r?glandium

Bug 1160798 - Work around --disable-compile-environment issues on Mac OS X. r?glandium

Comment 8

[Nick Alexander :nalexander [he/him]]

Attachment: MozReview Request: Bug 1160798 - Don't try to copy Cocoa binaries under --disable-compile-environment. r?glandium

Bug 1160798 - Don't try to copy Cocoa binaries under --disable-compile-environment. r?glandium

When --disable-compile-environment is enabled, PROGRAM is not defined.
This causes some problems because there are hacky Makefile.in rules
explicitly copying Cocoa binaries using PROGRAM.  This skips the
failing install rules.

Comment 9

[Nick Alexander :nalexander [he/him]]

glandium: I had these two commits from a while back.  The latter, not copying binaries, was intended for an artifact based build that has already moved binaries into dist/Nightly.app.  I did this because it's not trivial to map the contents of Nightly.app back into dist/bin.  Since your preference is to populate dist/Nightly.app from dist/bin, I wouldn't mind not landing the second part.  (We should definitely land something like the first part, to fix DCE on Mac OS X.)

Comment 10

[Mike Hommey [:glandium]]

Comment on attachment 8672313 [details]
MozReview Request: Bug 1160798 - Work around --disable-compile-environment issues on Mac OS X. r?glandium

https://reviewboard.mozilla.org/r/21685/#review19675

::: python/mozbuild/mozpack/executables.py:89
(Diff revision 1)
> +        'COMPILE_ENVIRONMENT' in substs and substs['COMPILE_ENVIRONMENT'])

This is dubious. What executable are there that would require stripping when building with --disable-compile-environment?

Comment 11

[Mike Hommey [:glandium]]

Comment on attachment 8672314 [details]
MozReview Request: Bug 1160798 - Don't try to copy Cocoa binaries under --disable-compile-environment. r?glandium

https://reviewboard.mozilla.org/r/21687/#review19677

::: toolkit/mozapps/update/updater/updater-xpcshell/Makefile.in:21
(Diff revision 1)
> +ifdef COMPILE_ENVIRONMENT #{

Why not limit this to the actual executables like in other files?

Comment 12

[:Gijs (he/him)]

What happened here? I think we got round this some other way. Should we just close WFM?

Comment 13

[Nick Alexander :nalexander [he/him]]

(In reply to :Gijs Kruitbosch from comment #12)
> What happened here? I think we got round this some other way. Should we just
> close WFM?

Yeah.