Omnijar breaks non-libxul builds

RESOLVED FIXED

Status

defect
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: bobbyholley, Assigned: benjamin)

Tracking

Trunk
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 beta5+)

Details

Attachments

(1 attachment)

I get this when building with --disable-libxul. Note that I've got some patches on top, so in theory they could be the problem, but I doubt it. 

Omnijar.cpp
Making symlinks to the original object files in the archive libraries ../../chrome/src/libchrome_s.a ../ds/libxpcomds_s.a ../io/libxpcomio_s.a ../components/libxpcomcomponents_s.a ../threads/libxpcomthreads_s.a ../proxy/src/libxpcomproxy_s.a ../base/libxpcombase_s.a ../reflect/xptcall/src/libxptcall.a ../reflect/xptcall/src/libxptcmd.a ../reflect/xptinfo/src/libxptinfo.a ../../dist/lib/libxpt.a ../string/src/libstring_s.a
Undefined symbols:
  "nsJAR::nsJAR()", referenced from:
      nsManifestZIPLoader::nsManifestZIPLoader()in nsManifestZIPLoader.o
      nsManifestZIPLoader::nsManifestZIPLoader()in nsManifestZIPLoader.o
  "nsZipArchive::OpenArchive(nsIFile*)", referenced from:
      SetupReader()      in Omnijar.o
  "nsZipArchive::CloseArchive()", referenced from:
      mozilla::SetOmnijar(nsILocalFile*)       in Omnijar.o
  "nsZipArchive::nsZipArchive()", referenced from:
      SetupReader()      in Omnijar.o
  "nsZipArchive::~nsZipArchive()", referenced from:
      mozilla::SetOmnijar(nsILocalFile*)       in Omnijar.o
      SetupReader()      in Omnijar.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[5]: *** [libxpcom_core.dylib] Error 1
make[4]: *** [libs] Error 2
make[3]: *** [libs_tier_platform] Error 2
make[2]: *** [tier_platform] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

I removed the line:

MOZ_CHROME_FILE_FORMAT=omni

from browser/confvars.sh, which fixed the problem.
Blocks: 556644
Summary: Omnijar breaks non-libxul builds → Omnijar breaks non-libxul builds on mac
Is this in fact Mac only?  It's not immediately apparent to me that it should be?
Affects my linux non-libxul build, too. Removing "on mac" from summary.
OS: Mac OS X → All
Hardware: x86 → All
Summary: Omnijar breaks non-libxul builds on mac → Omnijar breaks non-libxul builds
Version: unspecified → Trunk
The OS field in bugzilla is useless, please stop trying to read meaning into it.
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #466734 - Flags: review?(me)
(In reply to comment #3)
> Created attachment 466734 [details] [diff] [review]
> omnijar requires libxul, rev. 1
> 
> The OS field in bugzilla is useless, please stop trying to read meaning into
> it.


(the discussion had to do with the fact that I wrote "on mac" in the summary)
(FWIW, I based this on bug 556644 comment 122. Thanks for fixing it.)
blocking2.0: --- → beta5+
pushed http://hg.mozilla.org/mozilla-central/rev/7d4bf0f59616
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I have a feeling that something's wrong here with how those options work, probably because omnijar isn't really a chrome packaging option but looks that way currently. Also, if I tell the build to --enable-shared or do a debug build, I'd expect the build not to do an omnijar by default - but then, I might just have crazy thoughts and want automatic things that shouldn't be automatic. Why make it easy for developers when we can make it hard, after all :P
Yes, we are allergic to options automatically changing the behavior of other options. Developers should be aware of each non-default option they are changing.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.