3.48 KB, patch
Wan-Teh Chang: review+
|Details | Diff | Splinter Review|
2.67 KB, patch
|Details | Diff | Splinter Review|
941 bytes, patch
Wan-Teh Chang: review+
|Details | Diff | Splinter Review|
We still use gcc 3.3 with an SDK for the ppc build on the 1.8 branch. The 1.8 branch is still active for development for Camino 1.6 The 1.8 branch doesn't build on Leopard without the use of an SDK, so this bug effectively breaks development of Camino on PowerPC systems, and frustrates the development of universal builds of Camino on any system. The build (first?) fails in NSPR: gcc-3.3 -arch ppc -L/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/gcc/darwin -L/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib/gcc/darwin/3.3 -L/Developer/SDKs/MacOSX10.3.9.sdk/usr/lib -F/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks -F/Developer/SDKs/MacOSX10.3.9.sdk/Library/Frameworks -dynamiclib -compatibility_version 1 -current_version 1 -all_load -install_name @executable_path/libnspr4.dylib -headerpad_max_install_names -o libnspr4.dylib ./prvrsion.o io/./prfdcach.o io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o threads/./prtpd.o linking/./prlink.o malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o misc/./prtpool.o misc/./prtrace.o misc/./prtime.o malloc/./prmalloc.o pthreads/./ptsynch.o pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./darwin.o md/unix/./os_Darwin_ppc.o -framework CoreServices -framework CoreFoundation ld: file not found: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore /usr/bin/libtool: internal link edit command failed make: *** [libnspr4.dylib] Error 1 make: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc/nsprpub/pr/src' make: *** [export] Error 2 make: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc/nsprpub/pr' make: *** [export] Error 2 make: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc/nsprpub' make: *** [nspr] Error 2 make: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc' make: *** [alldep] Error 2 make: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc' make: *** [alldep] Error 2 make: Leaving directory `/lizard/1.8/mozilla' make: *** [alldep] Error 2 make: Leaving directory `/lizard/1.8/mozilla' In the above example, NEXT_ROOT is set to /Developer/SDKs/MacOSX10.3.9.sdk, which was supposed to inform ld to use that directory as its root system library directory instead of /. Unfortunately, when using NEXT_ROOT, this only appears to be effective for libraries specified on the command line. Dependencies are still sought as though they were /-relative. In this case, the CoreServices framework at /Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices depends on WebServicesCore, but WebServicesCore doesn't exist per se on Mac OS X 10.5: its exports have been merged into CoreServices.framework/Frameworks/OSServices.framework. A copy of WebServicesCore does exist in the 10.3.9 SDK at /Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore, but because ld is not using the SDK to look up dependencies, it doesn't find this framework. When ld is invoked with -syslibroot, it is able to properly resolve library dependencies. Note the following (NSPR and core): http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/nsprpub/configure.in&rev=188.8.131.52&mark=1048-1061#1048 http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/configure.in&rev=1.1503.2.105&mark=678-684#678 We should fix this bug by using -Wl,-syslibroot,$MACOS_SDK_DIR in $LIBS in NSPR and $MACOS_SDK_LIBS in core. We should only do this if the build host is Leopard, to avoid invasive changes to the build infrastructure on other build hosts. (ld -syslibroot support was only introduced in Tiger's build tools, so we will need to check the build hosts's support in any event, as the 1.8 branch still supports Panther build hosts.) I don't believe it's necessary to fix this bug on the trunk in the core, because we don't support gcc 3.3 for Mac there any longer. Any 3.3 build config support stuff on the trunk is a candidate for removal anyway. I don't know what NSPR's needs and requirements are outside of Mozilla client use. Wan-Teh, on what branches do you think it's appropriate to patch NSPR for this bug? For Camino development, we need to fix this on the NSPR branch that MOZILLA_1_8_BRANCH uses (and wait for a new NSPR tag?)
In this case, we will need to leave NEXT_ROOT set in the environment because it's also used by the compiler, and there's too much work involved in going through to make sure that compiler invocations set NEXT_ROOT on the command line while linker invocations use -syslibroot instead. Using both NEXT_ROOT and -syslibroot will result in these (harmless) warnings being printed at each linker invocation: /usr/bin/libtool: NEXT_ROOT environment variable ignored because -syslibroot specified
Created attachment 286742 [details] [diff] [review] NSPR patch This patch was generated against NSPR_4_6_7_RTM, as that's the tag that MOZILLA_1_8_BRANCH currently pulls.
Created attachment 286746 [details] [diff] [review] Core patch The same patch is needed in the core. These two patches were all that I needed to successfully complete a statically linked x86-to-ppc cross build of Camino using the 10.3.9 SDK.
Created attachment 286748 [details] [diff] [review] NSPR patch This one has a working regex pattern. Patch is against NSPR_4_6_7_RTM.
Created attachment 286749 [details] [diff] [review] Core patch Patch is against MOZILLA_1_8_BRANCH.
Created attachment 286751 [details] [diff] [review] NSPR patch Oh, man, today is NOT my day!
Created attachment 286752 [details] [diff] [review] Core patch
Comment on attachment 286751 [details] [diff] [review] NSPR patch r=wtc. Mark, we only need to fix this bug on NSPR_4_6_BRANCH and the NSPR trunk. Thanks for the patch.
Comment on attachment 286751 [details] [diff] [review] NSPR patch Great, this patch applies as-is (with an offset) on the NSPR trunk. Since the NSPR directories are under restricted despot control, Wan-Teh, can you check this patch into the NSPR trunk and 4.6 branch for me?
Comment on attachment 286752 [details] [diff] [review] Core patch Requesting approval184.108.40.206 for the core patch. This patch is required for developers using Leopard and working on the 1.8 branch. Camino still has active development on this branch, so we need to take this patch. It's purposely crafted to avoid changing anything at all on pre-10.5 systems, limiting risk. There's no equivalent trunk patch because the trunk no longer supports gcc 3.3 on Mac.
Comment on attachment 286751 [details] [diff] [review] NSPR patch I checked in the NSPR patch on the NSPR trunk (NSPR 4.7) and NSPR_4_6_BRANCH (NSPR 4.6.8).
Thanks, Wan-Teh. Let us know when NSPR 4.6.8 is released and tagged, since we'll want it for the 1.8 branch.
(In reply to comment #12) > Thanks, Wan-Teh. Let us know when NSPR 4.6.8 is released and tagged, since > we'll want it for the 1.8 branch. How quickly do you need it? Should this requirement push us to do the next release soon?
I'd like to get it in for 220.127.116.11 along with the core patch on this bug, but since the 1.8.1 drivers currently aren't doing approvals for 18.104.22.168 due to the 22.214.171.124 firedrill, it's not terribly urgent.
Mark, could you review NSS's coreconf build system and see if it needs to be updated? Thanks. http://lxr.mozilla.org/mozilla1.8/source/security/coreconf/Darwin.mk
Wan-Teh, I purposely didn't make any changes to NSS because NSS doesn't attempt to link against any of the affected libraries. This problem only existed in NSPR and the Mozilla core because both contain components that link against CoreServices, and older versions of CoreServices had dependencies that no longer exist in 10.5. The problem is purely one of link-time dependency resolution and has no impact on linker output. That said, if you'd like, I can prepare a patch for NSS too, to make its behavior more technically correct, and to guard against possible future library dependency changes in 10.6 and beyond like the CoreServices change in 10.5.
Mark, that would be nice but has a lower priority. No hurry. Since I thought of this potential issue after we built our NSS 3.11.8 release candidate last night, I just wanted to know if we missed anything.
Bug 402242 for NSS build changes.
Comment on attachment 286752 [details] [diff] [review] Core patch approved for 126.96.36.199, a=dveditz for release-drivers
I checked in the core patch for 188.8.131.52. Wan-Teh, there's no tag for NSPR 4.6.8 yet, although I thought you had released it. Will this be ready soon? I want to update client.mk to pull from an NSPR tag with this fix.
Mark, NSPR 4.6.8 is undergoing release testing now. I will let you know when we create the NSPR_4_6_8_RTM tag.
Mark, can you try build from the branch to verify that this is now fixed?
Al, we're waiting on the new NSPR tag here (see comment 20 and 21), and then the client.mk change to make Mozilla pick that up.
You can use the NSPR_4_6_8_RTM tag now.
Created attachment 290717 [details] [diff] [review] Use NSPR 4.6.8 on MOZILLA_1_8_BRANCH We need to move the 1.8 branch from NSPR 4.6.7 to 4.6.8 in order to pick up the NSPR portion of this patch (and also bug 401813). The differences between NSPR 4.6.7 and 4.6.8 can be viewed with: cvs diff -u8 -r NSPR_4_6_7_RTM -r NSPR_4_6_8_RTM mozilla/nsprpub
Comment on attachment 290717 [details] [diff] [review] Use NSPR 4.6.8 on MOZILLA_1_8_BRANCH r=wtc.
Note that this bug is not yet marked FIXED because it's targeted at the 1.8 branch only, and I'm waiting for the final 1.8 branch checkin (attachment 290717 [details] [diff] [review]).
Comment on attachment 290717 [details] [diff] [review] Use NSPR 4.6.8 on MOZILLA_1_8_BRANCH Don't want to approve an NSPR upgrade buried in another bug. Please file a new "upgrade NSPR on the branch" bug and make this one depend on it. Several other changes appear to have gone into NSPR and we'll need to evaluate the overall risk v. reward (where "build on leopard" is not that great a reward when there's risk involved).