Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 401768 - [10.5] Can't build with gcc 3.3 and an SDK on Leopard
: [10.5] Can't build with gcc 3.3 and an SDK on Leopard
: fixed1.8.1.10
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: 1.8 Branch
: All Mac OS X
: -- normal (vote)
: ---
Assigned To: Mark Mentovai
: Gregory Szorc [:gps]
Depends on:
  Show dependency treegraph
Reported: 2007-10-30 14:09 PDT by Mark Mentovai
Modified: 2007-12-17 16:48 PST (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

NSPR patch (3.47 KB, patch)
2007-10-30 14:37 PDT, Mark Mentovai
no flags Details | Diff | Splinter Review
Core patch (2.68 KB, patch)
2007-10-30 15:05 PDT, Mark Mentovai
no flags Details | Diff | Splinter Review
NSPR patch (3.42 KB, patch)
2007-10-30 15:20 PDT, Mark Mentovai
no flags Details | Diff | Splinter Review
Core patch (2.63 KB, patch)
2007-10-30 15:21 PDT, Mark Mentovai
no flags Details | Diff | Splinter Review
NSPR patch (3.48 KB, patch)
2007-10-30 15:28 PDT, Mark Mentovai
wtc: review+
Details | Diff | Splinter Review
Core patch (2.67 KB, patch)
2007-10-30 15:29 PDT, Mark Mentovai
ted: review+
dveditz: approval1.8.1.10+
Details | Diff | Splinter Review
Use NSPR 4.6.8 on MOZILLA_1_8_BRANCH (941 bytes, patch)
2007-11-29 11:07 PST, Mark Mentovai
wtc: review+
dveditz: approval1.8.1.12-
Details | Diff | Splinter Review

Description Mark Mentovai 2007-10-30 14:09:01 PDT
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[6]: *** [libnspr4.dylib] Error 1
make[6]: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc/nsprpub/pr/src'
make[5]: *** [export] Error 2
make[5]: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc/nsprpub/pr'
make[4]: *** [export] Error 2
make[4]: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc/nsprpub'
make[3]: *** [nspr] Error 2
make[3]: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc'
make[2]: *** [alldep] Error 2
make[2]: Leaving directory `/lizard/1.8/build/camino-universal-static/ppc'
make[1]: *** [alldep] Error 2
make[1]: 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):

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?)
Comment 1 Mark Mentovai 2007-10-30 14:14:54 PDT
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
Comment 2 Mark Mentovai 2007-10-30 14:37:58 PDT
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.
Comment 3 Mark Mentovai 2007-10-30 15:05:32 PDT
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.
Comment 4 Mark Mentovai 2007-10-30 15:20:42 PDT
Created attachment 286748 [details] [diff] [review]
NSPR patch

This one has a working regex pattern.  Patch is against NSPR_4_6_7_RTM.
Comment 5 Mark Mentovai 2007-10-30 15:21:17 PDT
Created attachment 286749 [details] [diff] [review]
Core patch

Patch is against MOZILLA_1_8_BRANCH.
Comment 6 Mark Mentovai 2007-10-30 15:28:52 PDT
Created attachment 286751 [details] [diff] [review]
NSPR patch

Oh, man, today is NOT my day!
Comment 7 Mark Mentovai 2007-10-30 15:29:23 PDT
Created attachment 286752 [details] [diff] [review]
Core patch
Comment 8 Wan-Teh Chang 2007-10-30 15:51:24 PDT
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 9 Mark Mentovai 2007-10-30 17:59:31 PDT
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 10 Mark Mentovai 2007-10-30 18:01:31 PDT
Comment on attachment 286752 [details] [diff] [review]
Core patch

Requesting approval1.8.1.10 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 11 Wan-Teh Chang 2007-10-31 11:08:23 PDT
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).
Comment 12 Mark Mentovai 2007-10-31 11:20:09 PDT
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.
Comment 13 Kai Engert (:kaie) 2007-10-31 13:52:01 PDT
(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?
Comment 14 Mark Mentovai 2007-10-31 14:15:40 PDT
I'd like to get it in for along with the core patch on this bug, but since the 1.8.1 drivers currently aren't doing approvals for due to the firedrill, it's not terribly urgent.
Comment 15 Wan-Teh Chang 2007-11-02 08:38:32 PDT
Mark, could you review NSS's coreconf build system and see if it
needs to be updated?  Thanks.
Comment 16 Mark Mentovai 2007-11-02 09:50:17 PDT
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.
Comment 17 Wan-Teh Chang 2007-11-02 09:57:59 PDT
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.
Comment 18 Mark Mentovai 2007-11-02 11:09:39 PDT
Bug 402242 for NSS build changes.
Comment 19 Daniel Veditz [:dveditz] 2007-11-07 15:23:09 PST
Comment on attachment 286752 [details] [diff] [review]
Core patch

approved for, a=dveditz for release-drivers
Comment 20 Mark Mentovai 2007-11-08 11:19:56 PST
I checked in the core patch for

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 to pull from an NSPR tag with this fix.
Comment 21 Wan-Teh Chang 2007-11-08 11:43:35 PST
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.
Comment 22 Al Billings [:abillings] 2007-11-15 16:34:30 PST
Mark, can you try build from the branch to verify that this is now fixed?
Comment 23 Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-11-15 22:07:24 PST
Al, we're waiting on the new NSPR tag here (see comment 20 and 21), and then the change to make Mozilla pick that up.
Comment 24 Wan-Teh Chang 2007-11-15 22:16:07 PST
You can use the NSPR_4_6_8_RTM tag now.
Comment 25 Mark Mentovai 2007-11-29 11:07:22 PST
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 26 Wan-Teh Chang 2007-11-29 15:01:03 PST
Comment on attachment 290717 [details] [diff] [review]
Use NSPR 4.6.8 on MOZILLA_1_8_BRANCH

Comment 27 Mark Mentovai 2007-11-30 12:44:32 PST
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 28 Daniel Veditz [:dveditz] 2007-12-17 16:10:45 PST
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).
Comment 29 Mark Mentovai 2007-12-17 16:48:57 PST
Bug 408755 for comment 28.

Note You need to log in before you can comment on or make changes to this bug.