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

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
4 years ago
8 months ago

People

(Reporter: nalexander, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

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

3 years ago
This also happens on Windows.

Comment 2

3 years ago
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...)
Flags: needinfo?(mh+mozilla)
That's a question for the person who added it.
Flags: needinfo?(mh+mozilla) → needinfo?(netzen)
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.
Flags: needinfo?(netzen)

Comment 5

3 years ago
Created attachment 8624337 [details]
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
Attachment #8624337 - Flags: review?(mh+mozilla)
Attachment #8624337 - Flags: review?(mh+mozilla)
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.
(Reporter)

Comment 7

3 years ago
Created attachment 8672313 [details]
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
Attachment #8672313 - Flags: review?(mh+mozilla)
(Reporter)

Comment 8

3 years ago
Created attachment 8672314 [details]
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.
Attachment #8672314 - Flags: review?(mh+mozilla)
(Reporter)

Comment 9

3 years ago
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 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?
Attachment #8672313 - Flags: review?(mh+mozilla)
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?
Attachment #8672314 - Flags: review?(mh+mozilla)

Comment 12

3 years ago
What happened here? I think we got round this some other way. Should we just close WFM?
Flags: needinfo?(nalexander)
(Reporter)

Comment 13

3 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(nalexander)
Resolution: --- → WORKSFORME

Updated

8 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.