Closed Bug 224161 Opened 21 years ago Closed 20 years ago

panther builds only run on panther

Categories

(SeaMonkey :: Build Config, defect)

PowerPC
macOS
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: david.haas, Assigned: leaf)

References

Details

Attachments

(4 files, 2 obsolete files)

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
Confirmed on 10.2.8.
*** Bug 224159 has been marked as a duplicate of this bug. ***
does this only happen with the nightly bits? if you back out the rendezvous
patch in bug 223323 can you launch a build?
Severity: normal → critical
FWIW I built from cvs yesterday (on 10.2.8) and it works fine on 10.2.8.
Summary: 10/29 nightly crash - 10.3 only? → 10/29 nightly crash
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.
Summary: 10/29 nightly crash → nightlies only run on panther
*** Bug 224264 has been marked as a duplicate of this bug. ***
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?
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. 
upgrading to blocker.

potentially useful thread: http://cocoa.mamasam.com/MACOSXDEV/2003/10/2/75604.php
Severity: critical → blocker
10.31 build still will not start up with 10.2.8.
*** Bug 224354 has been marked as a duplicate of this bug. ***
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.
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.
Assignee: pinkerton → leaf
Component: General → Build Config
Product: Camino → Browser
Version: unspecified → Trunk
*** Bug 224642 has been marked as a duplicate of this bug. ***
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
right, because the nightlies are being built on a jaguar machine until we solve
this issue.
Summary: nightlies only run on panther → panther builds only run on panther
Attached patch patch (obsolete) — Splinter Review
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.
why can't these env vars be set by configure.in? seems odd to have to do them on
the command line.
Attached patch alternative patch (obsolete) — Splinter Review
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.
Attachment #135967 - Attachment is obsolete: true
Attached patch updated patchSplinter Review
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
Attachment #136027 - Attachment is obsolete: true
Attachment #139600 - Flags: review?(bryner)
What does NEXT_ROOT mean?  Is it supposed to be set in
the environment?
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 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.
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.
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!
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)
> 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 on attachment 139600 [details] [diff] [review]
updated patch

r=me (pinkerton and I came up with this jointly)
Attachment #139600 - Flags: review?(bryner) → review+
wan-teh, do you have any objections to the NSPR portion of this patch? we'd like
to land this.
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 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)?
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?
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.
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 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).
Attachment #140090 - Flags: review+
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.
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.
(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)
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
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
     ;;
You need to patch configure.in, not configure (which is auto-generated).
The patch in Comment #41 looks good.  I've checked
it in (including the same change to nsprpub/configure.in).
Thanks for catching this.
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? :-)
clean up Xcode project.
thanks for that library path cleanup, odd that got in there. i think we're done
here, closing the bug.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: