Closed Bug 588075 Opened 11 years ago Closed 11 years ago
Omnijar breaks non-libxul builds
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: *** [libxpcom_core.dylib] Error 1 make: *** [libs] Error 2 make: *** [libs_tier_platform] Error 2 make: *** [tier_platform] Error 2 make: *** [default] Error 2 make: *** [build] Error 2 I removed the line: MOZ_CHROME_FILE_FORMAT=omni from browser/confvars.sh, which fixed the problem.
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)
Attachment #466734 - Flags: review?(me) → review+
(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.)
Status: ASSIGNED → RESOLVED
Closed: 11 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.
You need to log in before you can comment on or make changes to this bug.