224161 - panther builds only run on panther

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[David Haas (gone, not reading mail)]

Nightly from 10/29 crashes on launch (at least on my 10.2.6 box).  My guess is
it's been compiled specifically for 10.3.  Here's what the console is saying:

dyld: /Volumes/Camino/Camino.app/Contents/MacOS/Camino Undefined symbols:
/Volumes/Camino/Camino.app/Contents/MacOS/Camino undefined reference to
_SEC_AnyTemplate expected to be defined in Carbon
/Volumes/Camino/Camino.app/Contents/MacOS/Camino undefined reference to
_SEC_BitStringTemplate expected to be defined in Carbon
/Volumes/Camino/Camino.app/Contents/MacOS/Camino undefined reference to
_SEC_BooleanTemplate expected to be defined in Carbon
/Volumes/Camino/Camino.app/Contents/MacOS/Camino undefined reference to
_SEC_IntegerTemplate expected to be defined in Carbon
/Volumes/Camino/Camino.app/Contents/MacOS/Camino undefined reference to
_SEC_NullTemplate expected to be defined in Carbon
/Volumes/Camino/Camino.app/Contents/MacOS/Camino undefined reference to
_SEC_OctetStringTemplate expected to be defined in Carbon
/Volumes/Camino/Camino.app/Contents/MacOS/Camino undefined reference to
_SEC_UTCTimeTemplate expected to be defined in Carbon

Comment 1

[Robert Carr]

Confirmed on 10.2.8.

Comment 2

[Mike Pinkerton (not reading bugmail)]

*** Bug 224159 has been marked as a duplicate of this bug. ***

Comment 3

[Mike Pinkerton (not reading bugmail)]

does this only happen with the nightly bits? if you back out the rendezvous
patch in bug 223323 can you launch a build?

Comment 4

[S Woodside]

FWIW I built from cvs yesterday (on 10.2.8) and it works fine on 10.2.8.

Comment 5

[Mike Pinkerton (not reading bugmail)]

of course your build works fine. it was linked against the jaguar libs on your
local machine. the problem is the nightlies are linked against the panther libs
on my machine so they have symbols your mac doesn't.

Comment 6

[Mike Pinkerton (not reading bugmail)]

*** Bug 224264 has been marked as a duplicate of this bug. ***

Comment 7

[David Haas (gone, not reading mail)]

comment 3: Any chance someone with a 10.3 build machine could back out the patch
and post a build for us 10.2 users to see if it works?

Comment 8

[Mike Pinkerton (not reading bugmail)]

i don't think that patch has anything to do with it. to verify it, take the
morning build from 10.29 (which doesn't have the patch) and see if it runs on
jaguar.

my guess is that it's the SDK cross-dev issue. 

Comment 9

[S Woodside]

upgrading to blocker.

potentially useful thread: http://cocoa.mamasam.com/MACOSXDEV/2003/10/2/75604.php

Comment 10

[Jared James]

10.31 build still will not start up with 10.2.8.

Comment 11

[Mike Pinkerton (not reading bugmail)]

*** Bug 224354 has been marked as a duplicate of this bug. ***

Comment 12

[Neil Lee [:neilio]]

I just noticed that Pink duped bug #224354 to this. I'm getting the same crash
at launch, but I'm running 10.3, so this isn't just contained to the earlier
version of the OS.

Comment 13

[Mike Pinkerton (not reading bugmail)]

tbird has this same problem. i suspect mozilla would too. it's because apple is
shipping NSPR and NSS in CFNetwork, so we pick the symbols up there first before
our own. When we go to jaguar (which doesn't have them), we're looking in the
wrong place for the symbols and die.

this isn't a camino bug, it's a mozilla bug.

Comment 14

[Ludovic Hirlimann [:Usul]]

*** Bug 224642 has been marked as a duplicate of this bug. ***

Comment 15

[Ed Goham]

The last few nightly builds have run fine on my iMac G4 (FP) ::800MHz :: 768MB
:: 60GB :: SuperDrive :: Mac OS X 10.2.8 (6R65). Currently running Camino 2003111013

Comment 16

[Mike Pinkerton (not reading bugmail)]

right, because the nightlies are being built on a jaguar machine until we solve
this issue.

Comment 17

[Brian Ryner (not reading)]

Attachment: patch

These are the code changes required to support the cross development SDKs on
XCode.

After applying this patch (and regenerating configure), you can set these
variables in the environment:

CFLAGS="-I/Developer/SDKs/MacOSX10.1.5.sdk/usr/include"
LDFLAGS="-L/Developer/SDKs/MacOSX10.1.5.sdk/usr/lib"
NEXT_ROOT="/Developer/SDKs/MacOSX10.1.5.sdk"
MACOSX_DEPLOYMENT_TARGET=10.1

before running configure, and it should work.  Except for the project builder
projects in the tree, but pinkerton says he knows how to fix those.

Comment 18

[Mike Pinkerton (not reading bugmail)]

why can't these env vars be set by configure.in? seems odd to have to do them on
the command line.

Comment 19

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 135967 [details] [diff] [review]
patch

r=pink

Comment 20

[jhp (no longer active)]

Attachment: alternative patch

How about this?  Whoever actually has a build on Panther, can you check what
the value of TARGET_OS is in autoconf.mk?  I believe it should be "darwin7.0"
(this is what I am checking in the case statement).  Jaguar is "darwin6.8", and
10.1 is probably "darwin6.7" or lower.	I have not built with this, so I don't
know for sure it will work.

Also, I think that MACOSX_DEPLOYMENT_TARGET still needs to be set on the
command line.

Comment 21

[Mike Pinkerton (not reading bugmail)]

Attachment: updated patch

with this patch (and a native-target xcode project for camino) we can build
camino on panther and it runs on 10.2 and 10.1. note that we also had to add a
symlink to the sharedMenus framwork into the 10.2.8 SDK frameworks folder.

needing r/sr, and i'm sure wtc will want to look at the nspr portion

Comment 22

[Wan-Teh Chang]

What does NEXT_ROOT mean?  Is it supposed to be set in
the environment?

Comment 23

[Mike Pinkerton (not reading bugmail)]

NEXT_ROOT changes the root directory for the linker so that it can use the SDKs
that apple provides and not the actual libraries on the OS (which may pull in
dependencies not present on past OS versions).

it is set with a configure option, in our case it should be set to
/Developer/SDKs/MacOSX10.2.7.sdk/.

Comment 24

[Wan-Teh Chang]

Comment on attachment 139600 [details] [diff] [review]
updated patch

So only the linker uses the NEXT_ROOT environment variable?
Is this why we still need to modify the -I compiler flags?

Since NSPR can be built as an independent component, the
-with-macos-sdk=dir configure option and some of the related
stuff need to be added to nsprpub/configure.in,
nsprpub/config/autoconf.mk.in, and nsprpub/config/config.mk,
too.

Comment 25

[Mike Pinkerton (not reading bugmail)]

Attachment: nspr config changes

first stab at configure changes for nspr standalone. I don't think the
autoconf.mk/config.mk changes are necessary to bring over because nothing
inside nspr uses projectBuilder/XCode. wan-teh, can you give this a quick test
(I admit I'm flying blind here).

note i didn't include the makefile change from pr/src/linking in this patch
because i didn't want these two patches to overlap.

Comment 26

[Mike Pinkerton (not reading bugmail)]

and yes, to answer your question in comment 24, it only applies to the linker so
the -I's are necessary. If you can't tell, NEXT_ROOT is a hack, but it's Apple's
hack, not ours. They freely admit it's skanky but it's the only way to get there
from here. Yay!

Comment 27

[Javier Pedemonte]

So with this change, we'd always have to specify "--with-macos-sdk=..." in our
.mozconfig?  Why not have it default to /Developer/SDKs/MacOSX10.2.8.sdk, and
allow someone to specify "--with-macos-sdk=..." only if they want to override
this location?

Also, you do an "export $NEXT_ROOT" in configure.in and in config.mk.  Is it
needed in both places?

What is the reason behind this code:
@@ -4727,6 +4747,13 @@ MOZ_ARG_WITHOUT_BOOL(libIDL,
 if test "$SKIP_IDL_CHECK" = "no"
 then
     _LIBIDL_FOUND=
+    if test "$MACOS_SDK_DIR"; then 
+      changequote(,)
+      LIBS=`echo $LIBS|sed -e "s?-L${MACOS_SDK_DIR}/usr/lib[^ ]*??g"`
+      changequote([,])
+      unset NEXT_ROOT
+    fi
+
     if test "$MOZ_ENABLE_GTK2"; then
         PKG_CHECK_MODULES(LIBIDL, libIDL-2.0 >= 0.8.0,_LIBIDL_FOUND=1)
     fi
@@ -4753,6 +4780,10 @@ then
     if test -z "$_LIBIDL_FOUND"; then
         AC_MSG_ERROR([libIDL not found.
         libIDL $LIBIDL_VERSION or higher is required.])
+    fi
+    if test "$MACOS_SDK_DIR"; then
+      LIBS="-L${MACOS_SDK_DIR}/usr/lib/gcc/darwin/${GCC_VERSION}
-L${MACOS_SDK_DIR}/usr/lib $LIBS"
+      export NEXT_ROOT=$MACOS_SDK_DIR
     fi
 fi

Can you explain this line:
+PBBUILD=NEXT_ROOT= $(PBBUILD_BIN)

Comment 28

[Brian Ryner (not reading)]

> So with this change, we'd always have to specify "--with-macos-sdk=..." in our
> .mozconfig?  Why not have it default to /Developer/SDKs/MacOSX10.2.8.sdk, and
> allow someone to specify "--with-macos-sdk=..." only if they want to override
> this location?

You wouldn't _have_ to specify that, just if you want a build that works on
10.1/10.2.  The SDK is not going to be a build requirement afaik.

> Also, you do an "export $NEXT_ROOT" in configure.in and in config.mk.  Is it
> needed in both places?

Yes.  The export in configure is only for the duration of the configure script.

> What is the reason behind this code:

I'd originally intended it to get around the fact that the libIDL in recent Fink
distributions references symbols not present in MacOS 10.1.x, so it would fail
to link if you were using the 10.1 sdk.  My solution was to just remove the SDK
stuff from the compiler flags for running the libIDL test.  It turns out there
are other problems trying to build with the 10.1 sdk, and we really want to be
building with the 10.2 sdk (and the build will be fine on 10.1).  So we might be
able to get rid of that code.

> Can you explain this line:
> +PBBUILD=NEXT_ROOT= $(PBBUILD_BIN)

That tells the shell to unset NEXT_ROOT before invoking pbbuild.  While it's
true that pbbuild sets this variable itself if you use the cross development
SDK, it really doesn't seem to like being started with the variable already set.

Comment 29

[Brian Ryner (not reading)]

Comment on attachment 139600 [details] [diff] [review]
updated patch

r=me (pinkerton and I came up with this jointly)

Comment 30

[Mike Pinkerton (not reading bugmail)]

wan-teh, do you have any objections to the NSPR portion of this patch? we'd like
to land this.

Comment 31

[Wan-Teh Chang]

Comment on attachment 139660 [details] [diff] [review]
nspr config changes

I am not set up to test this NSPR patch, so I can't
review it.  I will comment on your other patch next.

Comment 32

[Wan-Teh Chang]

Comment on attachment 139600 [details] [diff] [review]
updated patch

The only NSPR change in this patch is the following
change to nsprpub/pr/src/linking/Makefile.in:

> # On Mac OS X use flat #includes.
> ifeq ($(OS_TARGET),MacOSX)
>-INCLUDES    += -I/Developer/Headers/FlatCarbon
>+ifdef NEXT_ROOT
>+INCLUDES    += -I$(NEXT_ROOT)/usr/include
>+endif
>+INCLUDES    += -I$(NEXT_ROOT)/Developer/Headers/FlatCarbon
> endif

The last + line is fine.

The first three + lines only apply to the files in
this directory, so all the other NSPR files will
still be compiled with the implicit -I/usr/include.
We should be consistent -- so we should either
remove the first three + lines or replace them by
the equivalent change to nsprpub/configure.in, which
would looks like:

>+if test "NEXT_ROOT"; then
>+  CFLAGS="-I${NEXT_ROOT}/usr/include $CFLAGS"
>+  CXXFLAGS="-I${NEXT_ROOT}/usr/include $CXXFLAGS"
>+fi

Could you test my suggested changes (with NSPR built
as part of the browser)?

Comment 33

[Mike Pinkerton (not reading bugmail)]

wan-teh, i tested your suggested change to nsprpub/configure.in and it works.
should we go ahead and land that and keep the other standalone patches in
progress until we can test them?

Comment 34

[Wan-Teh Chang]

pink: yes, let's do that.  Please attach that NSPR patch
(which assumes NEXT_ROOT is passed in via the environment)
and I'll review and check it in.

Comment 35

[Mike Pinkerton (not reading bugmail)]

Attachment: known working nspr patch for sdk support

wan-teh, this is the patch you asked me for (not including the stand-alone
changes) for NSPR. let's try to get this landed soon so we can get the other
mozilla stuff in. thanks!

Comment 36

[Wan-Teh Chang]

Comment on attachment 140090 [details] [diff] [review]
known working nspr patch for sdk support

r=wtc.

I've checked in this patch on the NSPR trunk (NSPR 4.5.1)
and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.7a).

Comment 37

[Martin Creutziger [:MMx]]

Any chances that a fix for this bug gets checked into FIREBIRD_0_8_BRANCH, too?
Would be nice to upgrade to Panther but still being able to build Firebird.

Comment 38

[Mike Pinkerton (not reading bugmail)]

i don't see much need for this to go on the fb branch. it builds already on
panther, the problem is that builds done on panther don't work on previous OS's.
So unless you plan on running your own local builds on other machines, you're fine.

Comment 39

[Martin Creutziger [:MMx]]

(In reply to comment #38)

Well - that's exactly what I want to do. Beeing able to run my builds on other
machines. 
That's pretty much what keeps me from updating to Panther (I unfortunately do
not posess a FW HDD or s.th. like it to install 2 OSes)

Comment 40

[Hiro]

The error of the following [ nsprpub/confiure ] has occurred.

./configure: line 1: NEXT_ROOT: command not found
./configure: line 1: NEXT_ROOT: command not found

Comment 41

[Hiro]

It corrected as follows and the error was fixed.
Index: configure
===================================================================
RCS file: /cvsroot/mozilla/nsprpub/configure,v
retrieving revision 1.78.2.79
diff -u -r1.78.2.79 configure
--- configure   4 Feb 2004 01:31:31 -0000       1.78.2.79
+++ configure   6 Feb 2004 14:19:04 -0000
@@ -3245,9 +3245,9 @@
     fi
 
     # do the right thing for panther SDK support
-    if test "NEXT_ROOT"; then
-        CFLAGS="-I$(NEXT_ROOT)/usr/include $CFLAGS"
-        CXXFLAGS="-I$(NEXT_ROOT)/usr/include $CXXFLAGS"
+    if test "$NEXT_ROOT"; then
+        CFLAGS="-I${NEXT_ROOT}/usr/include $CFLAGS"
+        CXXFLAGS="-I${NEXT_ROOT}/usr/include $CXXFLAGS"
     fi
     ;;

Comment 42

[Simon Fraser [no longer active]]

You need to patch configure.in, not configure (which is auto-generated).

Comment 43

[Wan-Teh Chang]

The patch in Comment #41 looks good.  I've checked
it in (including the same change to nsprpub/configure.in).
Thanks for catching this.

Comment 44

[Hiro]

The directory of Mike-san is included in the library reference path defined by
the Xcode project file.

/Users/pink/src/chimera/mozilla/profile/dirserviceprovider/src

Is this required? :-)

Comment 45

[Hiro]

Attachment: update xcode project

clean up Xcode project.

Comment 46

[Mike Pinkerton (not reading bugmail)]

thanks for that library path cleanup, odd that got in there. i think we're done
here, closing the bug.