XULRunner doesn't currently build on mac, for the following reasons: 1) It doesn't use the GNU linker, which means that we "ar" all the object files that make up the dylib. Unfortunately, there are three nsModule.o files in that list, and you get linker errors there. 2) -rpath-link apparently doesn't work for mac "ld". We need to use -executable-path instead. 3) Everything that links against -lxul needs to also link against -lobjc because of linker magic for objective-c that I don't understand. I'm hoping that if you link *just* against -lxpcom but not -lxul this isn't the case... we don't actually have any code that does this yet. 4) We were missing the .lproj directory.

I tried just linking against -lxpcom before, and I seem to recall that it didn't work without -lxpcom_core (or in this case -lxul). I find it hard to believe that applications must know about all libraries that xpcom depends on at link time, so perhaps we'll want to create a version of libxpcom.dylib for the Development Kit that does not have any link time dependency on libxul.dylib.

If you use -executable-path and/or -dylib-file you can link directly against -lxpcom without an ELF dependency on libxul.dylib, and I'm intending to implement that in our build system very soon. I don't think we need a compatibility libxpcom.dylib for the XDK, since they are going to have a xulrunner installed. All we need is a method to prevent the ELF dependency.

biesi points out that adding MOZ_JS_LIBS to xpcom/stub/Makefile.in unconditionally is wrong. I should move that into an ifdef MOZ_ENABLE_LIBXUL.

Comment on attachment 179129 [details] [diff] [review] Make XULRunner build on mac, rev. 2 This looks fine to me. Please ask justdave to move the nsModule.cpp files in CVS to preserve history.

(shouldn't this be filed against Toolkit:XULRunner?)

justdave, this one's for you!

Chase: ok with you?

(In reply to comment #9) > Chase: ok with you? Yup. After running the cvs-copy-file script you should doublecheck that the cvs commit time on each of the revisions is properly adjusted on the new file just as a sanity check for what the script should be doing. Thanks.

(In reply to comment #10) > (In reply to comment #9) > > Chase: ok with you? > > Yup. After running the cvs-copy-file script you should doublecheck that the cvs > commit time on each of the revisions is properly adjusted on the new file just > as a sanity check for what the script should be doing. Thanks. Completed, looks sane to me.

OK, all fixed.

One bit of this patch did not land yet. Reopening to get approvals.

This will only affect xulrunner builds, trivially safe.

Comment on attachment 179884 [details] [diff] [review] Configure change, reviewed but forgotten during checkin a=asa for 1.8b2 checkin.

bsmedberg: I also needed to add -Wl,-executable_path,$(DIST)/bin to EXTRA_DSO_LDOPTS in toolkit/library/Makefile.in and xpcom/stub/Makefile.in to build on Mac OSX using XCode 1.5.

Comment on attachment 179982 [details] [diff] [review] Really fix mac, rev. 1 >Index: toolkit/library/Makefile.in >+ifdef MOZ_ENABLE_XREMOTE >+COMPONENT_LIBS += remoteservice >+endif be sure to land carefully. otherwise, this patch looks right on! r=darin

Comment on attachment 179982 [details] [diff] [review] Really fix mac, rev. 1 a=asa

Attachment 179982 [details] [diff] committed on trunk.

Camino tbox is red. Link line contains -Wl,-executable_path,../../dist/bin which is meaningless.

It's meaningful on 10.3 which is where I was testing, but 10.2 doesn't recognize the flag. I've committed a temporary workaround and need to discuss the long-term plan with Darin.

Doesn't -executable_path need a parameter? E.g. -executable_path=../../dist/bin not -executable_path,../../dist/bin (note the comma).

The parameter should get passed to "ld" as "-executable_path <path>" The -Wl syntax is for options that that the compiler should pass directly to the linker, so: -Wl,option,option,option Which are munged into separate options by the gcc frontend.

from : http://developer.apple.com/releasenotes/DeveloperTools/CompilerTools.html New Features The static linker as option to find @executable_path dynamic libraries Added the -executable_path path_name option to ld(1) where path_name is is used to replace @executable_path for dependent libraries. Would this help ?

So... could this be causing the "creature" tinderbox orange? Did the shared libs changes mentioned in the checkin comment actually affect the Windows build?

Yes, it might be causing the creature orange and I think I have a clue. I built seamonkey static, but not seamonkey shared when testing, and seamonkey shared on win32 uses the XPCOM glue. I'm building/debugging now.

After testing, my hunch was incorrect. My non-static seamonkey appears to build and run without crash.

Todays nightly builds for Firefox and Thunderbird are showing a huge jump in file size for Mac OS X. Firefox is now 14MB on Mac OS X. And Thunderbird picked up 6MBs and is now a 17MB disk image. I filed Bug #290092 to track this. This bug seems to be the only thing that jumps out at me in the bonsai log.