401768 - [10.5] Can't build with gcc 3.3 and an SDK on Leopard

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mark Mentovai]

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

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/nsprpub/configure.in&rev=1.199.2.14&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?)

Comment 1

[Mark Mentovai]

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]

Attachment: 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]

Attachment: 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]

Attachment: NSPR patch

This one has a working regex pattern.  Patch is against NSPR_4_6_7_RTM.

Comment 5

[Mark Mentovai]

Attachment: Core patch

Patch is against MOZILLA_1_8_BRANCH.

Comment 6

[Mark Mentovai]

Attachment: NSPR patch

Oh, man, today is NOT my day!

Comment 7

[Mark Mentovai]

Attachment: Core patch

Comment 8

[Wan-Teh Chang]

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]

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]

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]

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]

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:]]

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

I'd like to get it in for 1.8.1.10 along with the core patch on this bug, but since the 1.8.1 drivers currently aren't doing approvals for 1.8.1.10 due to the 1.8.1.9 firedrill, it's not terribly urgent.

Comment 15

[Wan-Teh Chang]

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

Comment 16

[Mark Mentovai]

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]

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]

Bug 402242 for NSS build changes.

Comment 19

[Daniel Veditz [:dveditz]]

Comment on attachment 286752 [details] [diff] [review]
Core patch

approved for 1.8.1.10, a=dveditz for release-drivers

Comment 20

[Mark Mentovai]

I checked in the core patch for 1.8.1.10.

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.

Comment 21

[Wan-Teh Chang]

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 - ex-MoCo]]

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

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.

Comment 24

[Wan-Teh Chang]

You can use the NSPR_4_6_8_RTM tag now.

Comment 25

[Mark Mentovai]

Attachment: 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]

Comment on attachment 290717 [details] [diff] [review]
Use NSPR 4.6.8 on MOZILLA_1_8_BRANCH

r=wtc.

Comment 27

[Mark Mentovai]

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]]

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]

Bug 408755 for comment 28.