588075 - Omnijar breaks non-libxul builds

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Bobby Holley (:bholley)]

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.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Is this in fact Mac only?  It's not immediately apparent to me that it should be?

Comment 2

[Daniel Holbert [:dholbert]]

Affects my linux non-libxul build, too. Removing "on mac" from summary.

Comment 3

[Benjamin Smedberg]

Attachment: omnijar requires libxul, rev. 1

The OS field in bugzilla is useless, please stop trying to read meaning into it.

Comment 4

[Bobby Holley (:bholley)]

(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)

Comment 5

[Ben Bucksch (:BenB)]

(FWIW, I based this on bug 556644 comment 122. Thanks for fixing it.)

Comment 6

[David Dahl :ddahl]

pushed http://hg.mozilla.org/mozilla-central/rev/7d4bf0f59616

Comment 7

[Robert Kaiser]

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

Comment 8

[Benjamin Smedberg]

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.