292530 - Build on Mac OS X "Tiger" (10.4) (don't ask about gcc 4 here)

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mark Mentovai]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+

Mozilla will not build on Mac OS X "Tiger" 10.4, even using the "legacy" GCC 3.3
compiler bundled with the system's Xcode/Developer Tools 2.  Several aspects of
the system have changed:

Native build issues:

1. The system library now includes FSLockRange and FSUnlockRange functions that
conflict with the ones in xpcom/MoreFiles/MoreFilesX.c.  MoreFilesX comes from
Apple, so they broke their own API.  Mozilla does not use FSLockRange or
FSUnlockRange, so these functions can be unconditionally renamed or removed. 
This was first reported in bug 292266.

2. The sdp tool, used to prepare resources, has moved.  It was in
/Developer/Tools in former releases.  It is now in /usr/bin.  The Makefile in
xpfe/bootstrap/appleevents has a hardcoded path and needs to be updated. 
configure should check for the location of sdp.

3. The linker is being finicky when linking xpicleanup in xpinstall/cleanup,
treating the multiple definitions of strdup as a hard error.  It was formerly
treated as a warning.  strdup is defined in the system library and in
modules/libreg/src/vr_stubs.c (via libmozregsa_s.a).  I haven't investigated
enough to determine why ld's behavior has changed, but I can't imagine needing
to provide strdup on any Mac OS X variant, so it may as well go into an ifdef.

The above problems were encountered when building Firefox on Mac OS X 10.4 using
GCC 3.3 (sudo gcc_select 3.3).  Let's call this "phase 1."  Building with GCC
4.0 can be a later phase.  See bug 280479, bug 292266.

Cross-compilation issues:

With the problems above fixed, it is still difficult to target an older system
by specifying an alternate Mac OS X SDK when building on Mac OS X 10.4. 
(Install the appropriate cross-development packages in Xcode and add
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk to .mozconfig.
 This is the configuration recommended by Mozilla for release use, see
http://www.mozilla.org/build/release-build-notes.html .)

4. When specifying an alternate development SDK under host OS 10.4, C++ is
uncompilable because of problems including headers.  The list of include
directories is incomplete.  This was not a problem when building under earlier
versions of Mac OS X, because the system's own headers were "compatible enough"
with the headers in older SDKs.  When compiling C++, we need to search the
following subdirectories under SDK_PATH/usr/include/gcc/darwin/GCC_VERSION: c++,
c++/ppc-darwin, c++/backward, and ., as well as the standard C include directory
SDK_PATH/usr/include.  This information is gleaned from g++ -v.  Currently, only
the GCC_VERSION directory itself and the standard C include directory is
searched.  This is insufficient.

(XXX should we also add the proper Frameworks directories to the framework
search path using -F when building with an SDK?)

5. Note that the way these paths are built needs to be updated to support
Apple's GCC 4.  ppc-darwin is now powerpc-apple-darwin# (# being the
corresponding Darwin release major version being targeted).  GCC_VERSION needs
to be major.minor (4.0), but because Apple's GCC 4 identifies itself as 4.0.0,
the way that GCC_VERSION is constructed needs to be altered.  This doesn't
prevent the use of GCC 3.3 on 10.4, though.

6. Header incompatibility causes more problems when configure determines that a
header is available based on its presence in /usr/include, but it is not present
in the SDK.  For example, when targeting the 10.2.8 or 10.3.9 SDKs, when
building xpcom/obsolete/nsFileSpec.cpp, we include sys/types.h from the SDK and
sys/statvfs.h from /usr/include.  sys/statvfs.h is not present in the 10.2.8 or
10.3.9 SDKs, but is included because configure notices its presence in
/usr/include and sets HAVE_SYS_STATVFS_H.  sys/statvfs.h includes
machine/_types.h, also in /usr/include, which redefines, sometimes with
conflicts, the types already defined in the SDK's sys/types.h.  This is a
particularly hairy problem, and the only solution I can think of is to wrap
AC_CHECK_HEADERS checks for system headers in a test to check that the header is
present in the SDK (and not /usr/include) when building on a Mac with
with-macos-sdk selected.

(A similar problem to #6 will be present in the orbit libIDL installation,
because libIDL/IDL.h will want to include wchar.h from /usr/include, and wchar.h
also includes _types.h.  The only workaround is to eliminate the inclusion of
wchar.h from IDL.h when using an SDK.)

Reproducible: Always

Steps to Reproduce:

Comment 1

[Mark Mentovai]

Attachment: Fix issues 1-4

1. Rename FSLockRange and FSUnlockRange to MFX_FSLockRange and
MFX_FSUnlockRange (MFX, for MoreFilesX).

2. Make configure to check for the location of the sdp tool, and make sure it's
used.

3. Don't redefine strdup on Mac OS X.

4. C++ include path fix when targeting an older system.

No fix for 5 yet.  Although that's trivial, it's not necessary to build with
GCC 3.3, which is all I'm shooting for at this point.

No fix for 6 yet.  Would like some feedback on the proposed solution.

Comment 2

[Mark Mentovai]

I also tested the attached patch on a system running 10.3.9 with Xcode/DT 1.5
and gcc 3.3 and was able to build without incident, both with and without
with-macos-sdk specified.

Comment 3

[Mike Pinkerton (not reading bugmail)]

note that anything built with gcc4 requires 10.3.9 or later to run, so that
shouldn't be a concern for us for a VERY long time.

Comment 4

[Mark Mentovai]

Part 6, header conflicts between SDK and system, is still a problem when using
gcc 3.3 on a 10.4 build host.  It effectively means that you can't use a 10.4
host to target an older system release using any compiler.

Part 5's the only part that's gcc 4-specific.

Comment 5

[Cyrus Harmon]

(In reply to comment #3)
> note that anything built with gcc4 requires 10.3.9 or later to run, so that
> shouldn't be a concern for us for a VERY long time.

I don't see why building on gcc4 shouldn't be a concern for a very long time. Or I guess maybe I don't see 
who "us" is. I can understand that official firefox/moz/camino/tbird/etc... builds won't be done w/ gcc4 
(at least not MacOS) for a while, but I'd imagine there are mozilla folks for whom this would be at least an 
area of interest in the near future, if not a full-blown concern.

Comment 6

[Mark Mentovai]

(In reply to comment #5)
> I don't see why building on gcc4 shouldn't be a concern for a very long time.

That's not really the thrust of this bug.  The goal here is to build Mozilla on
Tiger using the existing (3.3) compiler.  Building with gcc 4 on the Mac is sort
of a moot issue for the time being, since Apple shipped a broken compiler.  I do
have Mozilla building with an in-development gcc 4, but the result is unstable,
so the issue really needs to wait for a working compiler.  Regardless, it
belongs in another bug.

The main issue here now is targeting an older system SDK with the older 3.3
compiler.

Comment 7

[Mike Pinkerton (not reading bugmail)]

yes, sorry for the gcc4 sidetrack. my actual intent was to make sure we didn't
get sidetracked talking about gcc4 (for all the reasons you mentioned). 

Boy, that sure worked out well.

Comment 8

[Cyrus Harmon]

(In reply to comment #6)
> That's not really the thrust of this bug.  The goal here is to build Mozilla on
> Tiger using the existing (3.3) compiler.  Building with gcc 4 on the Mac is sort
> of a moot issue for the time being, since Apple shipped a broken compiler.  I do
> have Mozilla building with an in-development gcc 4, but the result is unstable,
> so the issue really needs to wait for a working compiler.  Regardless, it
> belongs in another bug.
> 
> The main issue here now is targeting an older system SDK with the older 3.3
> compiler.

Fair enough. How about building without the cross-dev SDK using the older 3.3 compiler? Does this 
even make sense or do you need to use the SDKs w/ 3.3?

Also, is there a better way to select the 3.3 compiler than sudo gcc_select? Something on a per build or 
even per shell basis would be nicer.

When I try to set CC and CXX directly to the 3.3 versions and build I get the following error:

ld: Undefined symbols:
_fprintf$LDBLStub
_sprintf$LDBLStub
_vsnprintf$LDBLStub

Trying with gcc_select 3.3 now as I imagine just setting these directly isn't going to do the trick.

Comment 9

[Peter Van der Beken [:peterv]]

Adding "-nostdinc -F${MACOS_SDK_DIR}/System/Library/Frameworks" to CFLAGS and
"-nostdinc -nostdinc++ -F${MACOS_SDK_DIR}/System/Library/Frameworks" to CXXFLAGS
(in configure/configure.in) when $MACOS_SDK_DIR is set, seems to fix #6 for me.

Comment 10

[Cyrus Harmon]

(In reply to comment #1)
> Created an attachment (id=182336) [edit]
> 
> 2. Make configure to check for the location of the sdp tool, and make sure it's
> used.

Do I need to run autoconf or something after applying the patch to make this work? I get the following:

...
/Users/sly/src/mozilla/mozilla/mozilla/config/nsinstall -L /Users/sly/src/mozilla/mozilla/mozilla/
xpfe/bootstrap/appleevents -m 644 libappleevents_s.a ../../../dist/lib
NEXT_ROOT= @SDP@ -fa -o mozillaSuite.r ./mozilla.sdef 
/bin/sh: line 1: @SDP@: command not found
gmake[3]: *** [mozillaSuite.rsrc] Error 127
gmake[2]: *** [tier_50] Error 2
gmake[1]: *** [default] Error 2
gmake: *** [build] Error 2

Comment 11

[Mark Mentovai]

(In reply to comment #10)
> Do I need to run autoconf or something after applying the patch to make this
> work? I get the following:

Yes, Cyrus, the patch changes configure.in, so you need to run autoconf to
generate a new configure.

Comment 12

[Mark Mentovai]

Attachment: A more complete fix, allows SDK builds too

(In reply to comment #9)
Good call, Peter.

Setting CFLAGS and CXXFLAGS alone won't do the trick, because configure doesn't
apply them when checking for header files.  My initial thought was to set
CPPFLAGS, but there's no separate CXXCPPFLAGS, so it's kind of unclean.  Also,
the CPPFLAGS get carried over into the build CFLAGS and CXXFLAGS, and all kinds
of ugly things start happening.

So I moved the check for CPP and CXXCPP up a little bit (not far).  In the SDK
check, the appropriate flags get appended.  It's only a tiny bit ugly, it does
the trick, and it shouldn't break anything.

I am using -isystem instead of -I to have the include directories treated as
system include directories.  This avoids warnings about stddef.h redeclaring
wchar_t when compiling C++.  I also fixed part of issue 5.

Using -nostdinc exposed a problem in gfx/cairo/cairo/src/cairo_atsui_font.c,
which was including iconv.h even though the code that requires that header is
in an #if 0.  I put the include into an #if 0 as well.	Important for SVG
builds, fixed here.

Comment 13

[Mark Mentovai]

Attachment: Oops, this one's better

CXXFLAGS should build on CXXFLAGS, not CFLAGS.

Comment 14

[Mark Mentovai]

Attachment: Last one tonight, I promise

CXXCPP should also use C SDK include directories.

Comment 15

[Dave Chand]

I applied patch 4, but I the following errors came up when I ran the regenerated
configure.

checking whether gcc and cc understand -c and -o together... yes
./configure: line 6730: syntax error near unexpected token `macos-sdk,'
./configure: line 6730: `MOZ_ARG_WITH_STRING(macos-sdk,'
*** Fix above errors and then restart with "make -f client.mk build"
make: *** [/Users/dave/src/mozilla/Makefile] Error 1

Although I am not sure if I regenerated configure properly.

Comment 16

[Mark Mentovai]

Attachment: Only use -nostdinc for /usr/include, append includes to C(XX)FLAGS instead of prepend

It seems that any headers included in an isystem directory are implicitly
treated as extern "C", no good for C++.

I'm now using a Firefox produced by this patch, and am building a Seamonkey.

(In reply to comment #15)
Dave, you shouldn't have that text anywhere in configure, autoconf should have
transformed it when reading it from configure.in.  Be sure that you can build a
usable configure with an unpatched configure.in first.	The correct way to
build configure is to run autoconf while in the same directory as configure.in,
you need to be using autoconf 2.13 (not 2.5 or later) to do this.

Comment 17

[Dave Chand]

well for what its worth I used autoconf 2.13, inside mozilla source directory
where configure.in is, but I still get the following error.

./configure: line 2689: syntax error near unexpected token `macos-sdk,'
./configure: line 2689: `MOZ_ARG_WITH_STRING(macos-sdk,'

This is with and without the patch applied.

Comment 18

[Mike Pinkerton (not reading bugmail)]

note that for whatever patch is produced here, the only option we will check in
is building *with* the SDK. Using the 10.2.8 SDK is a requirement for builds we
distribute. Any solution needs to ensure that works.

also, i think the version of autoconf that moz requires is different (earlier)
from the one that ships with the OS. I seem to recall issues with this in the
past. bryner would remember for sure.

Comment 19

[Mike Pinkerton (not reading bugmail)]

mozilla requires the fink autoconf (v 2.13). The one that ships with the dev
tools won't work with mozilla. You can tell if you have the right one by doing
'which autoconf' and if it's in /sw/bin, you're ok.

building with the patch now.

Comment 20

[Mike Pinkerton (not reading bugmail)]

when i build camino (with the 10.2.8 sdk), I get:

ld: Undefined symbols:
_MOZ_Z_crc32
_MOZ_Z_inflateReset
_MOZ_Z_inflateEnd
_MOZ_Z_inflateInit_
_MOZ_Z_inflate
make[4]: *** [libimglib2.dylib] Error 1

Comment 21

[Frederic Bezies]

Not building on Tiger could be a 1.1 blocker. I am using Tiger, and it is far better than Panther. 
Requesting 1.1 blocker flag.

Comment 22

[Mark Mentovai]

pink: are you doing a clobber build?  The explanation that immediately jumps to
mind is that you did a build --without-system-zlib (or nothing at all, it's the
default) and are now doing a depend build --with-system-zlib over that.  I don't
get this error on a clobber build (or depend builds with the same
configuration), and I'm going with the default which gives
--without-system-zlib.  I've made a couple of changes since the last patch I
posted, but nothing that should affect this.

Is libimglib2.dylib being linked against -lmozz?
Does nm dist/lib/libmozz.dylib look sane?

Comment 23

[Mark Mentovai]

This shouldn't block 1.1 because it doesn't affect usage, only building.

Comment 24

[Mark Mentovai]

Re pink's zlib problem: on the second thought, it sounds like the problem is
limited to crc32.c and inflate.c in modules/zlib/src.  Can you check on the cc
for both of those, see if anything fishy is happening, and look at what symbols
they produce?

Comment 25

[Frederic Bezies]

Ok. I hope it will get fixed soon, as Tiger is going to be a great success...

My last useless comment on this bug ;)

Comment 26

[Dave Chand]

I am attempting to compile firefox with patch #5 but the build fails with the
following error:

c++ -o firefox-bin  -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith
-Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -fast -mcpu=7450 -fpascal-strings
-no-cpp-precomp -fno-common -fshort-wchar -I/Developer/Headers/FlatCarbon -pipe
 -DNDEBUG -DTRIMMED -fast -mcpu=7450  nsBrowserApp.o nsStaticComponents.o     
-L../../dist/bin -L../../dist/lib -L../../dist/lib/components -lxpcom_compat_c
-lxpconnect -luconv -lucvmath -li18n -lnecko -lnecko2 -ljar50 -lpref -lcaps
-lrdf -lhtmlpars -lgfx_mac -limgicon -limglib2 -lgkplugin -lwidget_mac
-lgklayout -ldocshell -lembedcomponents -lwebbrwsr -leditor -ltxmgr -lnsappshell
-loji -laccessibility -lchrome -lmork -lmozfind -lappcomps -lcommandlines
-ltoolkitcomps -lpipboot -lpipnss -lpippki -lcookie -lxmlextras -lautoconfig
-ltransformiix -luniversalchardet -lwebsrvcs -lpermissions -lsearchservice
-lbrowsercomps -lunicharutil_s -lucvutil_s -lgfxshared_s -lgkgfx -ljsj
-lxulapp_s ../../dist/lib/libxulapp_s.a -L../../dist/bin -lmozjs
-L../../dist/bin -lxpcom -lxpcom_core -L../../dist/lib -lplds4 -lplc4 -lnspr4
-lpthread -framework Cocoa -framework Carbon  -framework QuickTime -framework
IOKit -lm  -L../../dist/lib/components -L../../dist/lib -lmozpng
-L../../dist/lib -lmozjpeg -L../../dist/lib -lmozz  -L../../dist/bin
-L../../dist/lib ../../dist/lib/libcrmf.a -lsmime3 -lssl3 -lnss3 -lsoftokn3  
-L../../dist/lib -lxpcom_compat    
ld: warning suggest use of -bind_at_load, as lazy binding may result in errors
or different symbols being used
ld: Undefined symbols:
__ZThn4_N17nsHashPropertyBag11GetPropertyERK9nsAStringPP10nsIVariant
__ZThn4_N17nsHashPropertyBag13GetEnumeratorEPP19nsISimpleEnumerator
__ZThn4_N17nsHashPropertyBag17GetPropertyAsBoolERK9nsAStringPi
__ZThn4_N17nsHashPropertyBag17SetPropertyAsBoolERK9nsAStringi
__ZThn4_N17nsHashPropertyBag18GetPropertyAsInt32ERK9nsAStringPi
__ZThn4_N17nsHashPropertyBag18GetPropertyAsInt64ERK9nsAStringPx
__ZThn4_N17nsHashPropertyBag18SetPropertyAsInt32ERK9nsAStringi
__ZThn4_N17nsHashPropertyBag18SetPropertyAsInt64ERK9nsAStringx
__ZThn4_N17nsHashPropertyBag19GetPropertyAsDoubleERK9nsAStringPd
__ZThn4_N17nsHashPropertyBag19GetPropertyAsUint32ERK9nsAStringPj
__ZThn4_N17nsHashPropertyBag19GetPropertyAsUint64ERK9nsAStringPy
__ZThn4_N17nsHashPropertyBag19SetPropertyAsDoubleERK9nsAStringd
__ZThn4_N17nsHashPropertyBag19SetPropertyAsUint32ERK9nsAStringj
__ZThn4_N17nsHashPropertyBag19SetPropertyAsUint64ERK9nsAStringy
__ZThn4_N17nsHashPropertyBag20GetPropertyAsAStringERK9nsAStringRS0_
__ZThn4_N17nsHashPropertyBag20SetPropertyAsAStringERK9nsAStringS2_
__ZThn4_N17nsHashPropertyBag21GetPropertyAsACStringERK9nsAStringR10nsACString
__ZThn4_N17nsHashPropertyBag21SetPropertyAsACStringERK9nsAStringRK10nsACString
__ZThn4_N17nsHashPropertyBag22GetPropertyAsInterfaceERK9nsAStringRK4nsIDPPv
__ZThn4_N17nsHashPropertyBag22SetPropertyAsInterfaceERK9nsAStringP11nsISupports
__ZThn4_N17nsHashPropertyBag24GetPropertyAsAUTF8StringERK9nsAStringR10nsACString
__ZThn4_N17nsHashPropertyBag24SetPropertyAsAUTF8StringERK9nsAStringRK10nsACString
symbol _libVersionPoint used from dynamic library
../../dist/bin/libplc4.dylib(plvrsion.o) not from earlier dynamic library
@executable_path/libplds4.dylib(plvrsion.o)
make[4]: *** [firefox-bin] Error 1
make[4]: Leaving directory
`/Users/dave/src/mozilla/obj-powerpc-apple-darwin8.0.0/browser/app'
make[3]: *** [libs] Error 2
make[3]: Leaving directory
`/Users/dave/src/mozilla/obj-powerpc-apple-darwin8.0.0/browser'
make[2]: *** [tier_99] Error 2
make[2]: Leaving directory `/Users/dave/src/mozilla/obj-powerpc-apple-darwin8.0.0'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/Users/dave/src/mozilla/obj-powerpc-apple-darwin8.0.0'
make: *** [build] Error 2

Comment 27

[Mark Mentovai]

pink: I was backwards on that default for with-system-zlib, but I am able to
build through libimglib2.dylib both with-system-zlib and without-system-zlib.

Dave: don't use -fast/-O3, there are known problems with certain optimizations
(you know who you are, <cough>finline-functions<cough>) in GCC 3.3.  This is
invalid bug 289586.  Give it another shot with -O2 or less, or -Os.  Initial
testing is always better with conservative optimization.

Comment 28

[Frederic Bezies]

Applied patch and nothing works :(

Still blocked with a configure message saying :

checking for correct temporary object destruction order... no
configure: error: Your compiler does not follow the C++ specification for
temporary object destruction order.
*** Fix above errors and then restart with "make -f client.mk build"
make: *** [/Users/frederic/Documents/logs/fox/mozilla/Makefile] Error 1

My .mozconfig :

. $topsrcdir/browser/config/mozconfig

ac_add_options --disable-debug
ac_add_options --disable-tests

ac_add_options --enable-optimize="-Os -faltivec -mcpu=7450 -mtune=7450 -mpowerpc
-mpowerpc-gfxopt"

ac_add_options --enable-strip
ac_add_options --enable-prebinding

ac_add_options --enable-static
ac_add_options --disable-shared

ac_add_options --enable-svg

ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.2.8.sdk

Any tips to help ?

Comment 29

[Frederic Bezies]

Removing SDK line cure the last line bug ?!

A problem in gcc version selection ?!

Comment 30

[Mike Pinkerton (not reading bugmail)]

i'm building with the standard camino mozconfig

mozilla/camino/config/mozconfig

which uses the system zlib. i'm pretty sure that this was a clobber build, but i
can distclean again when i get home just to make sure. 

Comment 31

[Mark Mentovai]

Frederic, be sure you're not trying to use gcc 4.  I've only seen that problem
in relation to gcc 4.  The destructors fire properly, but compiling the test
program produces some junk on stderr.  If you're not using gcc 4, look in
config.log to see what's happening.

Comment 32

[Frederic Bezies]

Kinda stupid question. But how can I be sure that gcc 3.3 is used ?

I had both of them on my computer.

I will try to look at config.log and tell you what version is used, but I think
it is not gcc 3.3 :(

By the way, how can I be 100% sure to get gcc 3.3 used instead of gcc 4.0 ?

Comment 33

[Mike Pinkerton (not reading bugmail)]

$ gcc_select

will tell you the currently selected gcc version. the default is gcc4, so if 
you haven't done anything, you'll be on gcc4. To change it, run

$ sudo gcc_select 3.3

Comment 34

[Frederic Bezies]

Oups ! I thought configure will choose right gcc... So, if I understand well, I have to choose gcc 3.3 for 
now, until a new gcc 4.0 is out from Apple and cures the other known gcc 4.0 bug under OSX ?

Comment 35

[Mike Pinkerton (not reading bugmail)]

we need to choose gcc3.3 until mozilla drops support for anything before 10.3.9,
which will be a long time.

Comment 36

[Frederic Bezies]

Well, I will not build for a long time firefox because of fink not being
available  in a binary version for 10.4

When I use gcc_select 3.3, I cannot get libIDL to be detected...

Strange. Configure says me : libIdl >= 0.6.3 : no

But I had built libIdl 0.6.8 :(

/me is kinda fed up :(

Comment 37

[Mark Mentovai]

Attachment: v6

Changes since v5:
 - Determine GCC_VERSION even without SDK build so xcodebuild can use it
 - Export GCC_VERSION to the environment for xcodebuild
 - Do correct GCC_VERSION computation in preparation for gcc 4
 - Warn when gcc 4.0.0/4061 is used (hopefully avoiding the issue being
   reported)
 - Configure should fail when --with-macos-sdk doesn't point to a valid SDK
 - Warn during SDK build when libIDL-config is found but libIDL can't be used,
   suggest a workaround
 - Remove dependency on /usr/lib/libstdc++.a in
   modules/plugin/samples/default/mac/DefaultPlugin.pbproj
 - Camino default target (Camino) asks for -lmozz and attempts to copy
   libmozz.dylib even though the default mozconfig specifies --with-system-zlib


Open issues:
 - I would like to pass SDKROOT to xcodebuild for building DefaultPlugin and
   PrintPDE (and maybe even Camino) but the only good way to do it seems to
   be to transform the pbproj file after configure.  Kinda ugly.  Right now,
   DefaultPlugin and PrintPDE are built without specifying any SDK.  Camino
   uses the 10.2.8 SDK because its pbproj is hard-wired.
 - NSS never builds with an SDK specified, because it's got its own weird
   configuration system and it doesn't listen to $CFLAGS.  NSS is also the only

   part of the build that doesn't respect $CC.	Bug 93206 (CC), bug 101249
   (CFLAGS).
 - Should we set MACOSX_DEPLOYMENT_TARGET for ld when --macos-target is
   specified?

These two aren't really showstoppers and they've been present all along, but
the behavior with these problems isn't strictly correct and it COULD pose a
problem.

Other notes:
 - In configure, why are NEXT_ROOT and LIBS being unset and then reset during
   the libIDL check?
 - When building camino, I've never been able to build with xcodebuild, I can
   only do it in Xcode.app.  With this patch, I am able to build Camino under
   Tiger by running make and then opening Camino.xcode in Xcode when make dies.

   I used to have exactly the same problem under Panther.
 - Xcode 2 (the app) seems really crashy and screwed up.

Re comment 8, I tested this with setting CC and CXX to the 3.3 versions while
gcc_select was set to 4, and it now works properly.  I don't recommend it
though, in light of the NSS problem.

Re comment 36, Frederic, please read the last part of comment 0, and then edit
libIDL.h so that wchar.h is no longer included.  As of v6, configure will print
a warning about this, but it's not fatal so you need to watch for it.  This
patch will cause this same problem on 10.3 build hosts too.  It really is the
correct behavior, but the build machines will need to be checked and fixed
before this patch is checked in.

Mark

Comment 38

[Frederic Bezies]

Thanks for your answer. I will try to tweak libIDL.h and comment line including
wchar.h

Let's hope it will work this time...

Comment 39

[Karsten Düsterloh]

FWIW, I finally succeeded in compiling a non-optomized debug version of
SeaMonkey trunk with v5 of this patch under Tiger, with fink (selfupdated to
0.23.8)/fink autoconf 2.13/gcc 3.3 on my PB...

Comment 40

[Frederic Bezies]

Well, patch 6 + libIDL.h tweaking works.

Posting using a Tiger build of Firefox 1.0+ !

About:buildconfig says :

"about:buildconfig

Build platform
target
powerpc-apple-darwin8.0.0"

Let's hope building on Tiger will get simpler soon. Let's see for thunderbird,
now ;o)

Comment 41

[Mike Pinkerton (not reading bugmail)]

this is posted with camino debug, built from patch v6. awesome!!!

we should ensure that this patch still builds on panther (since tht's what the
nightlies and tinderboxen run).

Comment 42

[Mike Pinkerton (not reading bugmail)]

fwiw, i didn't need to tweak libIDL (i still use the fink binaries that i
upgraded from 10.3) and i built camino straight-through from the command line. I
didn't have to open the xcode project to finish building. I wonder what is
different in your setup that you need to do that.

Comment 43

[wrc_fan]

I tried building with the patch, and I'm getting this error:

In file included from xpidl.c:42:
xpidl.h:53:24:In file included from xpidl_idl.c:43 libIDL/IDL.h: No such file or
directory



IDL.h is located in /sw/include/libIDL-1.0/libIDL/IDL.h, and I'm using the same
fink binary install as I was in 10.3

Comment 44

[Frederic Bezies]

Mike, I made a really clean install of tiger. I prefer doing this than a
"archive and install" installation.

Let's hope panther could built it too ;o)

/me wants to see this bug closed as FIXED ;)

Comment 45

[Mark Mentovai]

Attachment: v7

v6-v7:
 - Remove space between -I and dir for C++ include directories
 - Handle configure brain death for GSS gracefully

Glad to have some positive feedback - we're well on the way!

The major update here is that negotiateauth is restored for SDK builds.  I
don't think anyone else noticed it was gone (yet).  configure handles the check
for GSS pretty stupidly.  It checks for it in a hard-coded location, /usr. 
That won't work for an SDK build, when we need to keep our filthy mitts out of
/usr.  Building on 10.4, configure detected major trouble and disabled
negotiateauth.	Building on 10.3, there was no major conflict at configure
time, so -I/usr/include and -L/usr/lib went right back in, and the build would
fail in extensions/negotiateauth due to a header conflict.

jwa: the most likely cause for that error is that you didn't edit IDL.h to not
include wchar.h.

Mike: I'm surprised that your IDL.h didn't need adjustment.  wchar.h was added
in 10.3, is it possible that your libIDL installation goes back further than
that?  For what it's worth, I'm using the same libIDL that I was using in 10.3
too (but not 10.2).

Believe it or not, my xcodebuild problem with Camino was caused by having CC
set in the environment.  It doesn't like CC in there at all, even if it's set
to a full path or if it's present but empty.  And it only affects certain parts
of the project: AddressBookManager.o won't build, but the pref panes will. 
Weird.

I am testing on 10.3 (using Xcode 1.1 against the 10.2.7 SDK - it's not a
computer I normally do dev on, so the toolchain is a little behind) as well as
10.4.  I'd appreciate it if other folks could test 10.3 (and 10.2) too.  There
are already a couple of caveats with this patch (libIDL.h), I really want to
avoid regressions.

Comment 46

[Mark Mentovai]

Tested with Thunderbird - OK.

I'd like to hear others' thoughts on the open issues in comment 37.

Comment 47

[Mike Pinkerton (not reading bugmail)]

> Camino uses the 10.2.8 SDK because its pbproj is hard-wired.

we should probably keep it this way, as if we set it only from the makefile, it
wouldn't be available when you built w/in xcode while developing.

i tested v7 on my panther box that i use for camino dev at work and it built
w/out modification to any files.

Comment 48

[Dave Chand]

My only problem now seems to be the patches v6 - v7 do not apply cleanly if I
only checkout "browser" source form the tree. 
The rest of the patch excluding patching
'mozilla/camino/Camino.xcode/project.pbxproj' applies cleanly.
Is they anything that can be done about the link error from comment #26
https://bugzilla.mozilla.org/show_bug.cgi?id=292530#c26 ? Or do we wait for
apply to fix their compiler.

Comment 49

[Mark Mentovai]

(In reply to comment #47)
> we should probably keep it this way, as if we set it only from the makefile,
> it wouldn't be available when you built w/in xcode while developing.

I was thinking that we could transform the pbxproj file by substituting SDKROOT
at or after configure time.  This is fine for objdir builds, and the more I
think about it, the more I don't hate the idea for non-objdir builds either.  I
might like it better if the pbxproj file was renamed to pbxproj.in or something.
 Do you ever need to open/build in the Xcode project before running configure? 
It seems pretty useless to me unless you've not only run configure but also done
a build of all of the stuff outside of pbxproj that the pbxproj depends on.

It's less of an issue for Camino than it is for the other pbxprojs, although if
I can come up with something that works well for those without hurting Camino,
it would make sense there too.

(In reply to comment #48)
> My only problem now seems to be the patches v6 - v7 do not apply cleanly if I
> only checkout "browser" source form the tree.

That's expected.  Just let patch skip that file.

> Is they anything that can be done about the link error from comment #26

That's a different bug (bug 289586) that most likely won't be fixed because it's
a compiler problem.  If you've got questions about it, please ask them in that bug.

Comment 50

[Mike Pinkerton (not reading bugmail)]

(In reply to comment #49)
>  Do you ever need to open/build in the Xcode project before running configure? 
> It seems pretty useless to me unless you've not only run configure but also done
> a build of all of the stuff outside of pbxproj that the pbxproj depends on.

I do that from time to time, using xcode to look at source or edit Camino files
on a clean tree before I build. *shrug*. Simon may have more of an opinion here.

Comment 51

[Mike Pinkerton (not reading bugmail)]

cc'ing simon ;)

Comment 52

[Frederic Bezies]

with v7, build process is crashing saying :

"nsFileSpec.cpp
c++ -o nsFileSpec.o -c  -DMOZILLA_INTERNAL_API -DOSTYPE=\"Darwin8.0.0\"
-DOSARCH=\"Darwin\" -DBUILD_ID=2005050707 -D_IMPL_NS_COM_OBSOLETE -I.. -I./../io
 -I../../dist/include/xpcom -I../../dist/include/string
-I../../dist/include/macmorefiles -I../../dist/include/xpcom_obsolete
-I../../dist/include -I../../dist/include/nspr    -I../../dist/sdk/include
-I/usr/X11R6/include   -fPIC  -I/usr/X11R6/include -fno-rtti -fno-exceptions
-Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -nostdinc
-nostdinc++ -I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++
-I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++/ppc-darwin
-I/Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3/c++/backward
-isystem /Developer/SDKs/MacOSX10.2.8.sdk/usr/include/gcc/darwin/3.3 -isystem
/Developer/SDKs/MacOSX10.2.8.sdk/usr/include
-F/Developer/SDKs/MacOSX10.2.8.sdk/System/Library/Frameworks
-F/Developer/SDKs/MacOSX10.2.8.sdk/Library/Frameworks -fpascal-strings
-no-cpp-precomp -fno-common -fshort-wchar
-I/Developer/SDKs/MacOSX10.2.8.sdk/Developer/Headers/FlatCarbon -pipe  -DNDEBUG
-DTRIMMED -Os -I/Developer/SDKs/MacOSX10.2.8.sdk/Developer/Headers/FlatCarbon 
-I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../mozilla-config.h
-Wp,-MD,.deps/nsFileSpec.pp nsFileSpec.cpp
In file included from nsFileSpec.cpp:520:
nsFileSpecUnix.cpp:59:25: sys/statvfs.h: No such file or directory
make[3]: *** [nsFileSpec.o] Error 1
make[2]: *** [tier_2] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2"

Sources up-to-date 10:00pm mozilla.org time.

Any explanation ?

Comment 53

[Mark Mentovai]

(In reply to comment #52)
You edited .mozconfig to switch from a non-SDK build to an SDK build without
dumping the results of the non-SDK build.  Remove objdir or run make distclean
(make clean is insufficient), and try again.  It's not safe to change the SDK
setting without rebuilding everything.

Comment 54

[Frederic Bezies]

Well, it looks like I made a mistake somewhere. Retrying with a blank new source
right now ;)

/me is sorry for spamming the bug :(

Comment 55

[Frederic Bezies]

Seamonkey can be build too (patch v7 too)

And the bug I reported before was my fault. I forgot to launch autoconf after
using the patch.

Comment 56

[Mark Mentovai]

Attachment: v8

Changes between v7 and v8
 - handle SDK builds properly in nsprpub (SDK taken from $NEXT_ROOT).  You
   now must run autoconf in nsprpub as well as in the top level.
 - fix libgfx_mac.dylib build to link Mozilla libraries before Carbon
   framework
 - configure: use $PERL instead of perl
 - set up include and lib directories properly for gcc 4 SDK builds
 - only use -F$MACOS_SDK_DIR/Library/Frameworks if it exists, avoiding ld
   warnings

Most of these changes are self-explanatory.  The libgfx_mac.dylib fix is
necessary because the 10.3.9 SDK's CFNetwork framework defines PR_Realloc and a
few other things included in NSPR.  Since these aren't present in libSystem in
10.4, a Panther-targeted build will not run on Tiger if it depends on those
symbols being in libSystem.  -framework Carbon needs to be moved after -lnspr4
when ld creates libgfx_mac.dylib.

Still pressing, getting closer...

Mark

Comment 57

[Mark Mentovai]

Attachment: v9

v8 was missing the libgfx_mac fix, v9 includes it

Comment 58

[David Becker]

I've tried to follow this thread by downloading the latest source from cvs,
applying the patch (which applied successfully, BTW) and running autoconf. 
However, autoconf didn't work for me, it returned the following:

build/autoconf/altoptions.m4:156: error: m4_defn: undefined macro:
_m4_divert_diversion
build/autoconf/altoptions.m4:153: MOZ_READ_MOZCONFIG is expanded from...
build/autoconf/altoptions.m4:156: the top level
autom4te-2.59: /sw/bin/gm4 failed with exit status: 1

Comment 59

[Mark Mentovai]

(In reply to comment #58)
> I've tried to follow this thread by downloading the latest source from cvs,
> applying the patch (which applied successfully, BTW) and running autoconf. 
> However, autoconf didn't work for me

You need to use autoconf 2.13.  Later versions, including the 2.59 that ships in
/usr/bin, are incompatible.  Since you seem to have fink, "fink install
autoconf" should give you 2.13 in /sw/bin/autoconf.

Comment 60

[Mark Mentovai]

(In reply to comment #37)
>  - I would like to pass SDKROOT to xcodebuild for building DefaultPlugin
>    and PrintPDE (and maybe even Camino) but the only good way to do it
>    seems to be to transform the pbproj file after configure.  Kinda ugly.
>    Right now, DefaultPlugin and PrintPDE are built without specifying any
>    SDK.  Camino uses the 10.2.8 SDK because its pbproj is hard-wired.

I found that Camino respects SDKROOT passed in via the environment or on the
xcodebuild command line.  So it should be possible to handle this without
dynamically modifying any of the project files.  That's nice and clean.

Unfortunately, for some reason, DefaultPlugin and PrintPDE aren't working the
same way.  In fact, even if I edit their pbxproj files (manually, by
proof-of-concept script, or by selecting an SDK in Xcode), they don't build
against an SDK.  I'd like to fix whatever's wrong with the pbproj files to make
them respect the SDK setting and then pass SDKROOT any time make calls xcodebuild.

>  - Should we set MACOSX_DEPLOYMENT_TARGET for ld when --macos-target is
>    specified?

I think this is probably a good idea.

Comment 61

[Frederic Bezies]

Last patch is working, but it is harder and harder to use it :)

A simple question : can I use gcc_select 4.0 or not, now ?

Any nspr problem with that idea ?

Comment 62

[Mark Mentovai]

> A simple question : can I use gcc_select 4.0 or not, now ?

Yes and no.  v8/v9 set up SDK builds to work with gcc 4, so the configure and
build system is ready.  But gcc 4 still won't work for reasons that have been
covered already, and the question really is spam in this bug.  This patch only
covers the configure and build system, the fact still remains that gcc 4 on the
Mac is broken in ways beyond our control at the moment.  See comment 6 and
comment 35.  I do plan on prepping the Mac-specific parts of the codebase for
gcc 4 as soon as I'm done here unless someone else gets it first, but the
results of that work still won't allow you to build a usable 'zilla with that
compiler.

Comment 63

[Peter Van der Beken [:peterv]]

v9 works for me with gcc 3.3 and /Developer/SDKs/MacOSX10.3.9.sdk.
I didn't have to edit IDL.h either (I installed Fink 0.7.1 using the binary
installer and installed binary packages for orbit, etc).

Comment 64

[Mark Mentovai]

(In reply to comment #63)
> v9 works for me with gcc 3.3 and /Developer/SDKs/MacOSX10.3.9.sdk.
> I didn't have to edit IDL.h either (I installed Fink 0.7.1 using the binary
> installer and installed binary packages for orbit, etc).

You don't need to edit IDL.h to target the 10.3.9 SDK.  10.3 includes wchar.h. 
Pre-10.3 systems, and thus pre-10.3 SDKs, don't have it.

One behavior I don't like is that if ORBit is found, configure just assumes that
libIDL works without testing it.  That means that it can't return a hard error
at configure time, and instead the build dies during make for reasons that may
seem unrelated to libIDL.  Especially now that IDL.h might not work without
tweaking, I think that it might be prudent for configure to actually test the
libIDL installation pointed to by orbit-config.

Comment 65

[Mark Mentovai]

(In reply to comment #60)
> Unfortunately, for some reason, DefaultPlugin and PrintPDE aren't working
> the same way.  In fact, even if I edit their pbxproj files (manually, by
> proof-of-concept script, or by selecting an SDK in Xcode), they don't build
> against an SDK.  I'd like to fix whatever's wrong with the pbproj files to
> make them respect the SDK setting and then pass SDKROOT any time make calls
> xcodebuild.

SDKROOT and various other settings work for native targets but not for legacy
targets.  Currently, DefaultPlugin and PrintPDE use jam (legacy) targets. 
Camino on the trunk was upgraded to use native targets.  Native targets only
function in Xcode (1.0 and up) and are not compatible with the older DT Project
Builder.  Xcode 1.0 requires (and shipped with) 10.3.

If upgraded to native targets, xcodebuild will build these projects respecting
any SDKROOT passed on the command line, and the command-line option will
override anything in the pbproj.  With the current Camino pbproj and mozconfig,
the build products will not change at all, and building from within Xcode.app
will still work.  Perfect.

So the question now is: is it OK to require 10.3 to build?  Currently, the
Mozilla minimum requirement is 10.2, but trunk Camino requires 10.3.  Even if we
upgrade the pbproj files so that they require Xcode, the older project files
could still be distributed and configure could be used to select which project
to use based on which build system is being used.  The only problem then is that
the legacy project would be prone to falling out of sync, but there aren't many
changes to either of the two projects in question.

I'd be surprised if any builders are still working with 10.2, but a big part of
me doesn't want to break this when a fix would be so trivial.

Comment 66

[Mike Pinkerton (not reading bugmail)]

it depends on how much you want to allow individual build environments to differ
from the production environment distributing binaries. All the tinderboxen and
nightly build machines are running panther and using the SDK to target 10.2.8
(even for seamonkey and firefox). 

sure, building on 10.2 still works, but it might cause people to make changes
that  have issues on the panther-based production machines w/out knowing it.

Comment 67

[Mark Mentovai]

Attachment: v10

Changes between v9 and v10
 - Much nicer handling of IDL that won't require anyone to edit any
   files on their systems.  If you edited IDL.h, please undo your
   changes.  If you were lucky enough to not have had to edit IDL.h,
   there are still some other goodies for you in this patch.
 - Check for usability of libIDL found via ORBit rather than assuming
   it will work.  This means problems with IDL.h will be treated as
   hard errors at configure time, rather than at compile time.	This
   change is for all platforms.
 - Do a better job with the check for GSS, to avoid adding unnecessary
   -I and -L flags that point to already-included directories.	This
   change is for all platforms.
 - Do not link Camino with libmozz for statically linked target
   (already covered non-static target).
 - Upgrade DefaultPlugin and PrintPDE to native targets, they now require
   Xcode.
 - Set GCC_GENERATE_DEBUGGING_SYMBOLS=NO for Deployment styles (was
   already set in Camino).
 - Turn on GENERATE_PKGINFO_FILE for DefaultPlugin target
 - Pass these settings to xcodebuild on the command line:
   - GCC_VERSION is now on the command line (it was in the environment
     in previous patches), USE_GCC3 can be removed from the Camino
     command line since GCC_VERSION replaces it.
   - SDKROOT, only set for SDK builds.	xcodebuild handles the SDK logic.
   - OPTIMIZATION_CFLAGS, only set if --enable-optimize had an argument
     in .mozconfig.  Otherwise, the project's default optimization is
     used.  GCC_MODEL_TUNING is set to empty to prevent Xcode from
     asking the compiler for -march, since the configuration's
     optimization specifications should be respected.
   - OTHER_CFLAGS gets the defines to enable or disable debugging.
   - MACOSX_DEPLOYMENT_TARGET when so requested (see below).
 - nspr uses OS_LIBS and not LIBS.
 - Propagate SDK-specifying CFLAGS (only) to XCFLAGS for NSS build.  The
   entire tree should now properly built against the selected SDK.
 - Export MACOSX_DEPLOYMENT_TARGET to the environment if
   --enable-macos-target is specified.	This lets ld take advantage of
   features only available in later OS versions.  --enable-macos-target
   remains independent of --with-macos-sdk.

I realized that IDL.h is only needed for xpidl, and xpidl only needs to run on
the build host.  Using the SDK to build xpidl is unnecessary.  The logic to
handle this was already partially in place, except SDK castration was only
being handled for ld and not for cc.

Builds now require 10.3 and Xcode (not sure if there's a minimum Xcode version,
but I'm testing with Xcode 1.1 now).  Mike was right: as soon as I had
converted the projects, I needed to make some changes, and I saw how tedious it
would have been to maintain the old Project Builder-compatible projects.  If
you need to build on 10.2, speak now or forever hold your peace.

The patch should be just about complete now.  Bang on it and let me know what
you've got it building (or not).

Notes for checkin time: remove/add these:

REM embedding/components/printingui/src/mac/printpde/PrintPDE.pbproj/
REM
embedding/components/printingui/src/mac/printpde/PrintPDE.pbproj/project.pbxproj

REM modules/plugin/samples/default/mac/DefaultPlugin.pbproj/
REM modules/plugin/samples/default/mac/DefaultPlugin.pbproj/project.pbxproj
ADD embedding/components/printingui/src/mac/printpde/Info-PrintPDE.plist
ADD embedding/components/printingui/src/mac/printpde/PrintPDE.xcode/
ADD embedding/components/printingui/src/mac/printpde/PrintPDE.xcode/ADD
project.pbxproj
ADD modules/plugin/samples/default/mac/Info-DefaultPlugin.plist
ADD modules/plugin/samples/default/mac/DefaultPlugin.xcode/
ADD modules/plugin/samples/default/mac/DefaultPlugin.xcode/project.pbxproj

Also, remember that Camino builds --without-system-zlib are probably broken
now.

Mark

Comment 68

[Frederic Bezies]

Tiger with gcc 3.3

Patch : v10
SDK used : 10.3.9

Building successfully : firefox and Thunderbird (both with sources up-to-date at
10:00pm mozilla.org time)

Did not try building camino for now. Will try later :) 

Comment 69

[Mark Mentovai]

Attachment: v11

Changes between v10 and v11
 - Turn GENERATE_PKGINFO_FILE back off for DefaultPlugin target and
   generate the PkgInfo file in the Makefile.  GENERATE_PKGINFO_FILE was
   added in Xcode 1.2 and does not work with Xcode 1.1.  This patch was
   tested successfully with Xcode 1.1 and Firefox; Camino is building now.
 - Camino Makefile.in changes were not included in v10, so PBBUILD_SETTINGS
   weren't being passed to xcodebuild.	For those of you who don't check out
   camino, you'll now need to let patch skip the first two files.
 - unexport CC and CXX in Makefiles that call xcodebuild to avoid problems
   (comment 45).  These cropped up with PrintPDE too once it was converted to
   a native target when CC was set in the environment.	As long as selected
   compiler is an Apple-provided one, xcodebuild is still able to find and use
   the proper compiler based on the GCC_VERSION setting.
 - Part of the Camino.xcode/project.pbxproj patch got checked in yesterday
   (v1.67), don't include that fragment in the patch to keep it up-to-date.

Comment 70

[Mike Pinkerton (not reading bugmail)]

oops, i didn't mean to check that in just yet. :) what's the impact, or should i
back it out?

Comment 71

[Mike Pinkerton (not reading bugmail)]

also, at what point do we want to try to get this reviewed and landed? I'm all
for fixing stuff, but can we land it and then refine it further so people can
build w/out needing to know about this bug?

Comment 72

[Mark Mentovai]

The only change that got checked in removed -lmozz from the Camino nonstatic
build (but didn't remove the libmozz dependency?)

I wasn't ready to ask for review yet before because there was still too much
stuff that was broken.  The IDL situation, for example.  I'm pretty confident in
it now, and I was planning on asking for review (prolly from you, with sr from
bryner) later today or tomorrow unless any big bugs popped up.

Comment 73

[Mike Pinkerton (not reading bugmail)]

i'm not a good person for review, i don't know most of the make machinery.

Comment 74

[Mark Mentovai]

'K.  I guess seawood'll be my victim then.

Comment 75

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I think we need to see this patch split into 3 pieces, at least:

- changes to the Mozilla core to permit it to build on Tiger
- changes to Camino to permit it to build on Tiger
- other build-system enhancements

That will make it much more likely that we get good review on those pieces, and
get them in promptly.  There are some pieces that I don't understand, like why
the existing HOST_PROGRAMS stuff doesn't work for xpidl, but I'd rather make
sure I'm looking at the right (necessary) parts, and that I can get build-system
folks to look at them as well.

Comment 76

[jhp (no longer active)]

Mark, have you tested this patch on any other platform (Win32, Linux), just to
be sure your cross platform changes are legit?

Comment 77

[Mark Mentovai]

Attachment: v11, annotated

Shaver: Most of the patch is required for either 10.4 builds or SDK builds on a
10.4 host.  Both are essential.  I looked at splitting it, and there are no
really clear boundaries, except for the stuff that's Camino-only in the first
couple of files.

I've annotated the patch with a brief description of each fragment, and my
assessment of whether or not the change is required or an enhancement.	Note
that even most of the enhancements are in there to enforce the application of
an SDK when one is selected - while they're not strictly necessary to build and
run, they're mandatory for correctness, and are waiting to become problems the
next time Apple changes a header file if they're not addressed.

I've also marked off what each change is needed for (Camino, SDK builds, 10.4
builds, any Mac builds, etc.)

As for the xpidl HOST_PROGRAMS stuff: it would probably work (although we'd
still need a special case since a normal cross build isn't set up and we'd
still need to pull NEXT_ROOT out of the environment.)  I didn't do that because
the OS X SDK was already special-cased for xpidl and that seemed like the
proper place to handle it.

Javier: I haven't tested on non-Mac platforms, but I've marked in the annotated
patch the fragments that affect other platforms.

Comment 78

[jhp (no longer active)]

Just built with this patch on Linux, and it worked as expected (no build breaks,
browser comes up, no noticeable differences between patched and non-patched builds).

Comment 79

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I must not have made myself clear, for which I apologize.

I want to see the patch split up.  I am not arguing against making the build
system more future proof, or "correct", or whatever.  I am arguing against
presenting this patch at a 65K monolith.

Once we build on Tiger, we can fix the build to work on other future updates and
so forth.  Mixing these things together makes it harder to review, and ties the
necessary build-on-Tiger fixes to the other enhancements and Camino fixes. 
(Which latter should almost certainly be reviewed separately, if only because
they apparently break build-on-Jaguar.)

Factoring and applying an annotated patch sounds like a pretty painful
experience, given how context matching works, so I think it'd be best to split
them into 3 of the categories you've outlined (SDK-usage fixes, camino fixes,
core 10.4-build fixes), and attach separate patches.  And when you asked for my
review, you asked what I thought. =)

Comment 80

[Mark Mentovai]

Attachment: Phase 1: Allow SDK-less builds on 10.4

Mike, that makes much more sense.  I think I was getting caught up in the
delineations.  These categories make sense.

Phase 1: Allow SDK-less builds on 10.4
 - build: Handle now-variable location of sdp tool
 - xpcom/MoreFiles: Work around redefinition of prototype
 - modules/libreg/src/vr_stubs.c: Do not implement strdup

Comment 81

[Mark Mentovai]

Attachment: Phase 2: Allow SDK-ful builds on 10.4

Phase 2: Allow SDK-ful builds on 10.4
 - configure.in: Logic reorganization to accommodate
 - configure.in: Much better handling of CFLAGS, CXXFLAGS, and LIBS needed
   for SDK builds
 - configure.in: GSSAPI check does not use -I/-L to find GSSAPI in system
   directories
 - configure.in: do libIDL checks without SDK as IDL is only needed by the
   build host
 - xpcom/typelib/xpidl/Makefile.in: do xpidl build without SDK for reason
   above
 - extensions/java/xpcom/tools/xpidl/Makefile.in: as above
 - gfx/cairo/cairo/src/cairo_atsui_font.c: wrap unused iconv.h in #if 0
   (the implementation that depends on the header is already inside #if 0)
 - gfx/src/mac/Makefile.in: link with Carbon framework after NSPR
   libraries

Comment 82

[Mark Mentovai]

Attachment: Phase 3: Correct behavior for all non-core parts of the build system

Phase 3: Correct behavior for all non-core parts of the build system
(Make them respect the selected SDK)
 - build: send SDKROOT to xcodebuild
 - embedding/components/printingui/src/mac/printpde: update Xcode project
   to native target to handle SDK for Xcode projects
 - modules/plugin/samples/default/mac: as above
 - nsprpub/configure.in: handle SDK for NSPR
 - security/manager/Makefile.in: handle SDK for NSS
This patch is not as large as it seems - the old pbproj directories disappear
and are replaced by new xcode directories, accounting for 2/3 of the bulk of
this guy.

Comment 83

[Mark Mentovai]

Attachment: Phase 4: Miscellaneous enhancements

Phase 4: Miscellaneous enhancements
 - build: Set MACOSX_DEPLOYMENT_TARGET for ld when the configure option
   --enable-macos-target is used
 - build: Pass a variety of other settings to Xcode projects being built:
   GCC_VERSION, MACOSX_DEPLOYMENT_TARGET, GCC_MODEL_TUNING,
   OPTIMIZATION_CFLAGS, and OTHER_CFLAGS
 - configure.in: Soft warning when using the default compiler shipping
   with 10.4, it is buggy
 - configure.in: Hard error if specified SDK is missing
 - configure.in: When finding libIDL via ORBit, check to make sure it is
   usable

Comment 84

[Mark Mentovai]

Attachment: Phase 5: Camino fixes

Phase 5: Camino fixes
 - Do not depend on libmozz in the Xcode project, Camino should be using
   --with-system-zlib
 - Accept xcodebuild settings to properly set selected SDK

Comment 85

[Mark Mentovai]

Comment on attachment 183240 [details] [diff] [review]
Phase 5: Camino fixes

These guys are meant to be applied in order.  Although I haven't tested them
individually, they were tested as a whole (v11).  Except for phase 5, I'm not
sure who to tag for review.

There was one change since v11: there were two checks for
MACOSX_DEPLOYMENT_TARGET when one would have done, this is in phase 4.

Comment 86

[Frederic Bezies]

Cannot apply patch phase 1, patch says :

$ patch -p0 < 292530.ph1.1.patch 
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- mozilla/config/autoconf.mk.in.dist 2005-04-22 16:58:52.000000000 -0400
|+++ mozilla/config/autoconf.mk.in.ph1  2005-05-10 19:23:20.000000000 -0400
--------------------------
File to patch: 

What's the problem here ? Patch v11 is working well :(

Comment 87

[Mark Mentovai]

(In reply to comment #86)
> Cannot apply patch phase 1, patch says :

That's a patch to config/autoconf.mk.in, I forgot to update the filenames in it
so they're artifacts of how I generated the patch.

If you apply patches ph1 through ph5 in sequence, you'll get the same result as
v11, with the one minor change mentioned in comment 85.

Comment 88

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 183164 [details]
v11, annotated

(removing outdated review req on v11-annotated)

I'll try (ugh) to get some time for at least the core patches this week, but
please don't skip over another reviewer to save them for me!

Comment 89

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 183164 [details]
v11, annotated

(removing outdated review req on v11-annotated)

I'll try (ugh) to get some time for at least the core patches this week, but
please don't skip over another reviewer to save them for me!

Comment 90

[Mark Mentovai]

Comment on attachment 183236 [details] [diff] [review]
Phase 1: Allow SDK-less builds on 10.4

OK.  Pointing it at seawood for his autoconf/build familiarity and bryner for
Mac familiarity.  shaver and everyone else, your two centses will still be
accepted if you find the time.

Comment 91

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 183240 [details] [diff] [review]
Phase 5: Camino fixes

r=pink

Comment 92

[Frederic Bezies]

Why the f**k this bug is marked as fixed ? It isn't because patches are not added to trunk !

Comment 93

[Ginn Chen]

I'm so sorry.
I just want to add a "CC:".
Wrong click, sorry for that.

Comment 94

[Brian Ryner (not reading)]

Comment on attachment 183238 [details] [diff] [review]
Phase 3: Correct behavior for all non-core parts of the build system

Do we actually have to migrate the PrintPDE and Default Plugin projects to
xcode 2 to make them build?  It would be great if we could leave them in the
old format for now.

Comment 95

[Mark Mentovai]

bryner: The updated PrintPDE and DefaultPlugin projects work in Xcode 1 (10.3).
 The update is necessary to make them build against an SDK.  Old-style jam
(legacy) targets don't know or care about SDKROOT.  New-style "native" targets
do, but they require Xcode.  This makes the minimum build requirement for
Mozilla 10.3 and Xcode.  I have used this patch to build on 10.3/Xcode 1.1. 
Note that Camino already requires 10.3 to build.  Mozilla now requires 10.2 at
minimum, and while I don't want to break that just for the sake of breaking it,
I question whether anyone actually needs to build on 10.2 any more.

It would be possible, as I mentioned earlier, to distribute both an .xcode
project and a .pbproj project alongside one other.  We could select which to use
based on whether we're using xcodebuild/pbproj (Xcode) or pbxproj (Project
Builder).  This would maintain buildability on 10.2.  I initially wanted to do
this (comment 65) but had a change of heart.  The machinery wouldn't be a
problem, but maintaining two separate projects could become tedious.  Also,
testing the machinery would necessarily require a 10.2 machine.  Anyone got?

Comment 96

[cls]

Comment on attachment 183236 [details] [diff] [review]
Phase 1: Allow SDK-less builds on 10.4

Can you split the MoreFiles changes into a separate patch for darin &
pinkerton/simon to review?  I'm not sure why we would just rename those
functions instead of just removing them completely since it doesn't look like
any of the callers were renamed.

Looking at the collection of patches, there's no AC_SUBST for SDP so the value
never gets substituted in autoconf.mk.

Comment 97

[cls]

Comment on attachment 183237 [details] [diff] [review]
Phase 2: Allow SDK-ful builds on 10.4

For the Makefile changes, you should use $(shell) rather than the backticks.  

Since you are rearranging that section anyway, can you just move the option
checks for --with-macos-sdk & --with-java-include down to the 'External
Packages' section?  They do not need to be up there with the compiler tools
checks.

Comment 98

[Mark Mentovai]

Attachment: Phase 1a: SDK-less builds on 10.4, config/build portion

Splitting phase 1 into a configure/build half and a Mac-specific implementation
half per comment 96.

Chris, I do AC_PATH_PROG for SDP, and AC_PATH_PROG calls AC_SUBST.  This is the
documented behavior for AC_PATH_PROG.  I'll add a redundant AC_SUBST if you
insist, but I don't see why it should be necessary.

Comment 99

[Mark Mentovai]

Attachment: Phase 1b: SDK-less builds on 10.4, Mac-specific implementation portion

Re comment 96: removing those functions in MoreFilesX is an option, since there
are no calls to them in Mozilla.  I renamed because those files were untouched
from the copies Apple supplies, and renaming with a comment seemed like a less
obtrusive and easier to follow change in the event that Apple ever updates and
we sync.

Comment 100

[cls]

Comment on attachment 183238 [details] [diff] [review]
Phase 3: Correct behavior for all non-core parts of the build system

r=cls iff wtc also approves of the NSPR & NSS changes.

Comment 101

[cls]

Comment on attachment 183648 [details] [diff] [review]
Phase 1a: SDK-less builds on 10.4, config/build portion

(In reply to comment #98)
> Chris, I do AC_PATH_PROG for SDP, and AC_PATH_PROG calls AC_SUBST.  This is the
> documented behavior for AC_PATH_PROG.  I'll add a redundant AC_SUBST if you
> insist, but I don't see why it should be necessary.

Looking at the docs, you're correct.  I must've forgotten to run autoconf after
applying the patch. Sorry about that.

Comment 102

[Mark Mentovai]

Attachment: Phase 2, v2: Allow SDK-ful builds on 10.4

(In reply to comment #97)
> For the Makefile changes, you should use $(shell) rather than the backticks. 


Done.

> Since you are rearranging that section anyway, can you just move the option
> checks for --with-macos-sdk & --with-java-include down to the 'External
> Packages' section?  They do not need to be up there with the compiler tools
> checks.

I moved --with-java-include down, but --with-macos-sdk needs to run very early.
 The changes it makes to CPP, CFLAGS, and friends are critical to the build
process.  I did a small reorg to put the OS X toolchain stuff back where I
found it and moved --with-macos-sdk just below that.  It can probably move a
little bit more down, but it really needs to remain above any AC_TRY or
anything else that does cpp, cc, ld, etc.  So at the very least, it needs to
stay in the same section.

This patch may change the context for subsequent patches such that they won't
apply.	Also, recent changes on the trunk may prevent subsequent patches from
applying cleanly.  If any reviewer wants something more up-to-date, just ask. 
I plan on at least cutting a new (unified or split into phases?) patch once the
reviews are in.

Also, some people have privately expressed interest to me in a backport of the
patch to the aviary 1.0.x branch once this lands on the trunk.	I was thinking
that at least the critical ph1 and ph2 patches could be backported.  Any
opinions on this?  Does the stable branch usually take core build config
changes to build on newer hosts?

Comment 103

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 183649 [details] [diff] [review]
Phase 1b: SDK-less builds on 10.4, Mac-specific implementation portion

r=pink

Comment 104

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 183648 [details] [diff] [review]
Phase 1a: SDK-less builds on 10.4, config/build portion

This patch doesn't apply for me, because it apparently diffs between *.dist and
*.ph1, neither of which exist in my source tree.  I guess I'll whack it with
some sed, but I wonder if I'm doing something wrong.

Comment 105

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 183649 [details] [diff] [review]
Phase 1b: SDK-less builds on 10.4, Mac-specific implementation portion

sr=shaver.

Comment 106

[Mark Mentovai]

You're not doing anything wrong.  I shoulda whacked it with sed, especially
after comment 86, but I forgot.  Just drop the .dist/.phX suffixes.

Comment 107

[Wan-Teh Chang]

Comment on attachment 183238 [details] [diff] [review]
Phase 3: Correct behavior for all non-core parts of the build system

cls: the NSPR change looks OK.	I didn't review it carefully though.

Could you implement the NSS change inside mozilla/security/coreconf
as opposed to in mozilla/security/manager/Makefile.in?	This way
standalone NSS builds will also work.

Comment 108

[Chase Phillips]

(In reply to comment #102)
> Also, some people have privately expressed interest to me in a backport of the
> patch to the aviary 1.0.x branch once this lands on the trunk.	I was thinking
> that at least the critical ph1 and ph2 patches could be backported.  Any
> opinions on this?

Yes, it is more likely that only the critical fixes be taken.

> Does the stable branch usually take core build config
> changes to build on newer hosts?

This has happened in certain cases but I wouldn't say that those cases are
usual.  Usually only security fixes and patches for regressions from previous
security fixes are committed on the branches.

Comment 109

[Mark Mentovai]

(In reply to comment #107)
> Could you implement the NSS change inside mozilla/security/coreconf
> as opposed to in mozilla/security/manager/Makefile.in?  This way
> standalone NSS builds will also work.

wtc: That's not so simple.  MACOS_SDK_FLAGS is filled with the results of a
bunch of scripted logic.  I can export that variable and pick it up in
security/coreconf/Darwin.mk, but the variable itself will still need to be set
up by a top-level configure, so it's not that useful for a standalone NSS build.
 The only way to make it work standalone would be to pick up NEXT_ROOT in
security/coreconf and use it to rebuild MACOS_SDK_FLAGS - a reimplementation of
the top-level configure logic, like I've done in NSPR's configure.  I guess
that's OK, if you don't mind having a script in security/coreconf to build the
flags.  A quick perl job could handle it.  I'd do that if you wanted it, but I
think it should be in another bug, or at least a separate part of this bug.

Comment 110

[Brian Ryner (not reading)]

Comment on attachment 183238 [details] [diff] [review]
Phase 3: Correct behavior for all non-core parts of the build system

Do we really need to fork the project files at this point?  Can't the new
version of xcodebuild deal with old-format project files?

Comment 111

[Mark Mentovai]

bryner: if we leave the pbproj files alone, xcodebuild won't listen when we
specify SDKROOT, and we wind up building without the SDK.  It's an invitation
for trouble.  The whole rest of the build uses the SDK.

I just want to make clear that the newer pbprojs still work with Xcode 1.x on 10.3.

Comment 112

[Wan-Teh Chang]

Comment on attachment 183652 [details] [diff] [review]
Phase 2, v2: Allow SDK-ful builds on 10.4

>+    dnl If gcc >= 4, use powerpc-apple-darwin#, where # is the version of
>+    dnl the Darwin release corresponding to the target Mac OS X release.
>+    dnl For OS X >= 10.1.1, take the minor version number and add 4 to get
>+    dnl the Darwin major version number.  If it can't be determined, use the
>+    dnl current Darwin major version number and hope that there's a symlink.
>+    TARGET_ARCH_LIB=powerpc-apple-darwin`echo $MACOS_SDK_DIR | $PERL -pe 's/MacOSX10\.([^\.]*)//;if ($1) {$_=$1+4;} else {$_="'$TARGET_OS'";s/(\d+)//;$_=$1;}'`

Why don't you use the existing MACOS_VERSION_MINOR variable
to compute the Darwin major version number?

Comment 113

[Mark Mentovai]

(In reply to comment #112)
> Why don't you use the existing MACOS_VERSION_MINOR variable
> to compute the Darwin major version number?

MACOS_VERSION_MINOR tells us which deployment target has been selected by
--enable-macos-target, and defaults to 1 (as in 10.1).  This is not the same
thing as which version the selected SDK is associated with (set by
--with-macos-sdk in top-level, and NEXT_ROOT in nsprpub) or the version of the
system running on the build host (TARGET_OS, used only for fallback when the
version can't be figured based on what's in NEXT_ROOT).

Comment 114

[Wan-Teh Chang]

Comment on attachment 183238 [details] [diff] [review]
Phase 3: Correct behavior for all non-core parts of the build system

Mark,

Yes, I'd like you to reimplement that logic in mozilla/security/coreconf.

Here is some makefile code I put together.  Since I don't have a Mac, I
can only test it on Linux to the best I can.

ifndef GCC_VERSION
    GCC_VERSION_FULL := $(shell $(CC) -v 2>&1 | grep "gcc version" | sed -e
"s/^.*gcc version[  ]*//" | awk '{ print $$1 }')
    GCC_VERSION_MAJOR := $(shell echo $(GCC_VERSION_FULL) | awk -F. '{ print
$$1 }')
    GCC_VERSION_MINOR := $(shell echo $(GCC_VERSION_FULL) | awk -F. '{ print
$$2 }')
    GCC_VERSION := $(GCC_VERSION_MAJOR).$(GCC_VERSION_MINOR)
endif

ifndef DARWIN_TARGET_MAJOR
    DARWIN_TARGET_MAJOR := $(shell echo $(NEXT_ROOT) | sed -e
's/^.*MacOSX10\.//' | awk -F. '{ print $$1 }')
    ifeq (,$(DARWIN_TARGET_MAJOR))
	DARWIN_TARGET_MAJOR := $(shell echo $(OS_RELEASE) | awk -F. '{ print
$$1 }')
    else
	DARWIN_TARGET_MAJOR := $(shell expr $(DARWIN_TARGET_MAJOR) + 4)
    endif
endif

ifeq (,$(filter-out 2 3,$(GCC_VERSION_MAJOR)))
# GCC <= 3
else
# GCC >= 4
endif

Comment 115

[Wan-Teh Chang]

Comment on attachment 183238 [details] [diff] [review]
Phase 3: Correct behavior for all non-core parts of the build system

I'd like to suggest some changes to the nsprpub portion
of this patch.

Replace the comment "top-level configure.in" by
"Mozilla's top-level configure.in" or "mozilla/configure.in".

Since NSPR only uses the C compiler, it is better to define
GCC_VERSION_FULL, GCC_VERSION, and GCC_VERSION_MAJOR using
$(CC) -v instead of $(CXX) -v.

It would be nice if you could copy from mozilla/configure.in
the comments that explain what those Perl scripts do.

NSPR has no makefile rules that use CPP or CXXCPP, so they
don't need to be defined.

TARGET_OS is not defined in mozilla/nsprpub/configure.in, so
you need to replace $TARGET_OS with ${target_os}.

Comment 116

[Mark Mentovai]

Attachment: Phase 3, v2: implement wtc's suggestions

(In reply to comment #114)
(NSS) Good call.  This is much better.

(In reply to comment #115)
(NSPR) OK.  The only thing I didn't implement is this:

> NSPR has no makefile rules that use CPP or CXXCPP, so they don't need to be
> defined.

CPP needs to be defined because AC_CHECK_HEADER uses it.  I've added a comment
to clarify why I do this, in both nsprpub/configure.in and the top-level
configure.in.

Comment 117

[Mark Mentovai]

Attachment: Phase 2, v3: changes inspired by wtc's review of ph3

Changes since ph2v2 and ph2v3:
 - SDK_C_INCLUDE needs to use GCC_VERSION_FULL in lib for gcc4
 - use ${target_os} instead of $TARGET_OS (only necessary in nsprpub, but
   it's better in top-level too)
 - add comment re setting CPP and CXXCPP

This patch already had sr+, I don't see why these updates should change that.

Note that these patches (and hopefully subsequent ones) have been processed so
they should apply without having to tell patch which file to work on.

Comment 118

[Mark Mentovai]

Comment on attachment 183156 [details] [diff] [review]
v11

v11 is now obsolete, I'll cut a new unified patch once they're all stable.

Comment 119

[Wan-Teh Chang]

Comment on attachment 183868 [details] [diff] [review]
Phase 3, v2: implement wtc's suggestions

I only reviewed the nsprpub and security/coreconf changes.

I see that ac_cpp is defines as $CPP $CPPFLAGS.  It seems
that it's better to add those flags to $CPPFLAGS instead
of $CPP, but I know why you don't do that -- ac_compile
uses both $CFLAGS and $CPPFLAGS, so those flags would be
added redundantly.

In mozilla/security/coreconf/Darwin.mk, you can use
ifneq instead of ifeq-else.  I don't think you need to
define LDOPTS.	You have a comment about including
-F$(NEXT_ROOT)/Library/Frameworks if it exists.  If
Mac allows passing a nonexistent directory to -F, we
can just add that blindly.  Otherwise, we'd need to
make a $(shell ) function call to test the existence of
that directory.

Comment 120

[Mark Mentovai]

(In reply to comment #119)
> I see that ac_cpp is defines as $CPP $CPPFLAGS.  It seems
> that it's better to add those flags to $CPPFLAGS instead
> of $CPP, but I know why you don't do that -- ac_compile
> uses both $CFLAGS and $CPPFLAGS, so those flags would be
> added redundantly.

Yup.  Not only that, but for C++, ac_cpp is $CXXCPP $CPPFLAGS.  There's no
separate $CXXCPPFLAGS.  It doesn't matter for NSPR, but it's imperative where
plusplus is concerned.

> In mozilla/security/coreconf/Darwin.mk, you can use
> ifneq instead of ifeq-else.

Noted and updated, thanks.

> I don't think you need to define LDOPTS.

Not for the Mozilla build, but aren't there things linked into executables
during a standalone build?

> You have a comment about including
> -F$(NEXT_ROOT)/Library/Frameworks if it exists.

I knew I forgot something!

> If
> Mac allows passing a nonexistent directory to -F, we
> can just add that blindly.  Otherwise, we'd need to
> make a $(shell ) function call to test the existence of
> that directory.

The compiler spits warnings for missing -F directories (like -L), so I wanted to
make it conditional.  Added this after setting DARWIN_SDK_LDFLAGS:

ifneq (,$(shell find $(NEXT_ROOT)/Library/Frameworks -maxdepth 0))
    DARWIN_SDK_CFLAGS += -F$(NEXT_ROOT)/Library/Frameworks
endif

The only changes in ph3v2 were to NSPR and NSS, so with r=cls on v1 for
everything else save that, and r=wtc on v2 for that save everything else, it
should be good to go.

I'll have limited availability from the 19th to the 25th, it'd be nice to wrap
up by tomorrow.  The only remaining issue as I see it is how to handle (or not)
building on 10.2.

Comment 121

[Wan-Teh Chang]

Mark,

You may know the NSS build system better than I do now :-)
I found that $(LDOPTS) is in two NSS command-line utilities'
makefiles, but I am not sure if it is really being used.

Here is the makefile rule we use to build executables in NSS:
http://lxr.mozilla.org/security/source/security/coreconf/rules.mk#290

Now that I have looked at our makefiles more closely, I think
you should replace LDOPTS by OS_LIBS, although it is strange to
see a bunch of -L's without any -l.  (We only link with libSystem.dylib
implicitly.)  Will those -L's apply to libSystem.dylib if we
don't have -lSystem explicitly on the command line?

Comment 122

[Wan-Teh Chang]

Mark, you can also try setting LDFLAGS (instead of LDOPTS)
in mozilla/security/coreconf/Darwin.mk.  I don't know whether
OS_LIBS or LDFLAGS is more appropriate, but I believe either will
work.

I've determined that the two NSS makefiles in which I found
$(LDOPTS) are dead files, so definitely do not set LDOPTS.

Comment 123

[Mark Mentovai]

I changed LDOPTS to LDFLAGS and still set it with +=.  It seems that the other
mk fragments in coreconf are more likely to set OS_LIBS, but LDFLAGS and OS_LIBS
aren't used independently.  I'm more comfortable calling -L a "flag" than a library.

With proper coaxing via -L, ld will use the libSystem we want.  Actually, when
NEXT_ROOT is set, it should look where that points and not at /usr/lib at all. 
The -L flags are more to point ld at the compiler-specific lib dirs in the SDK,
since the compiler doesn't know about NEXT_ROOT or have any other one-stop way
to ask for an SDK.  This whole bug would be so much easier if it did.

Comment 124

[edburns]

I'm trying to build 1.7.7 from the source tarball on MacOS X 10.4 Tiger.  I'm
using the stock GCC that came with the Xcode 2 on my machine.  I know this may
not be supported, but until the build instructions are updated, I thought I'd
post here.

I renamed the FSLock and FSUnlock methods but now the build fails here:

sCollationMacUC.cpp: In member function `virtual nsresult
nsCollationMacUC::CompareString(PRInt32, const nsAString&, const nsAString&,
PRInt32*)':
nsCollationMacUC.cpp:223: error: invalid conversion from 'PRInt32*' to 'SInt32*'
nsCollationMacUC.cpp:223: error:   initializing argument 7 of 'OSStatus
UCCompareText(OpaqueCollatorRef*, const UniChar*, UniCharCount, const UniChar*,
UniCharCount, Boolean*, SInt32*)'
nsCollationMacUC.cpp: In member function `virtual nsresult
nsCollationMacUC::CompareRawSortKey(const PRUint8*, PRUint32, const PRUint8*,
PRUint32, PRInt32*)':
nsCollationMacUC.cpp:244: error: invalid conversion from 'PRInt32*' to 'SInt32*'
nsCollationMacUC.cpp:244: error:   initializing argument 6 of 'OSStatus
UCCompareCollationKeys(const UCCollationValue*, ItemCount, const
UCCollationValue*, ItemCount, Boolean*, SInt32*)'

Comment 125

[Dave Chand]

regarding comment #124; You are using gcc 4.0, use gcc_select to switch to gcc
3.3. Doing that will eliminate those compiler errors you are having.

Comment 126

[Josh Aas]

Please use "cvs diff -u" to create patches. "u" is a standard option, and the
file names in your patches don't match up with what gets checked out...

Comment 127

[Mark Mentovai]

I usually use cvs diff -u, but for the interphase patches, that won't work.  I'm
 still using diff -u, and in later versions, am also fixing the diffs to apply
cleanly.

I see that there's r+/sr+ all around now, I'll cut a new patch against current
cvs when I return, then we can think about a checkin.

Comment 128

[dales]

(In reply to comment #127)
> I usually use cvs diff -u, but for the interphase patches, that won't work.  I'm
>  still using diff -u, and in later versions, am also fixing the diffs to apply
> cleanly.
> 
> I see that there's r+/sr+ all around now, I'll cut a new patch against current
> cvs when I return, then we can think about a checkin.

One item I've noted is the phase 4.1 patch does not apply cleanly.  Here's the
terminal capture of applying the patch to yesterday's mozilla source archive:

pcp04368799pcs:~ dales$ patch -p0 < dales292530.ph4.1.patch 
patching file mozilla/config/autoconf.mk.in
Hunk #2 FAILED at 517.
1 out of 2 hunks FAILED -- saving rejects to file mozilla/config/autoconf.mk.in.rej
patching file mozilla/config/config.mk
patching file mozilla/configure.in
Hunk #1 FAILED at 458.
Hunk #2 succeeded at 2433 (offset -14 lines).
Hunk #3 succeeded at 2454 (offset -14 lines).
Hunk #4 succeeded at 5781 (offset -3 lines).
1 out of 4 hunks FAILED -- saving rejects to file mozilla/configure.in.rej
pcp04368799pcs:~ dales$ 

All other phases apply cleanly now ... though I had to edit some names with
*.dist or *.ph# stuctures to get it to happen.  No tests of phase 5 were done,
since I'm not doing Camino builds.

Environment is Panther ... 10.3.9 and gcc 3.3.

Dale

Comment 129

[Mark Mentovai]

patch can't resolve some conflicts due to recent checkins.  Stand by, it'll be
up to date by Thursday at the latest.

Comment 130

[Mark Mentovai]

Attachment: v12: up to date, consolidated

I'm back, this time with a suntan.

This patch is the consolidation of all six phase patches that have r+/sr+,
including the changes discussed with wtc, brought up to date relative to
current cvs.  No phases, no diff silliness, applies cleanly against a virgin
tree.

There's no way this should hold up 1.1a1/1.8b2, so we'll hold off on getting
this checked in until those are out and the tree is unfrozen.

Notes for checkin: the following files and directories are removed:
embedding/components/printingui/src/mac/printpde/PrintPDE.pbproj/
embedding/components/printingui/src/mac/printpde/PrintPDE.pbproj/project.pbxproj

modules/plugin/samples/default/mac/DefaultPlugin.pbproj/
modules/plugin/samples/default/mac/DefaultPlugin.pbproj/project.pbxproj

The following files and directories are added:
embedding/components/printingui/src/mac/printpde/Info-PrintPDE.plist
embedding/components/printingui/src/mac/printpde/PrintPDE.xcode/
embedding/components/printingui/src/mac/printpde/PrintPDE.xcode/project.pbxproj

modules/plugin/samples/default/mac/Info-DefaultPlugin.plist
modules/plugin/samples/default/mac/DefaultPlugin.xcode/
modules/plugin/samples/default/mac/DefaultPlugin.xcode/project.pbxproj

Comment 131

[Josh Aas]

Thanks! The tree may open as soon as tomorrow and we should get this in ASAP. I
will do the commit (after some testing) unless somebody else wants to.

Comment 132

[Frederic Bezies]

Thanks for the one-for-all patch. I will test it on both firefox and thunderbird
asap.

Comment 133

[Josh Aas]

Using Mac OS X 10.4.1 on a G5, with gcc 3.3 selected and fresh checkouts...

When building Firefox with your patch, I get this:

NEXT_ROOT= /usr/bin/xcodebuild -project DefaultPlugin.xcode -target "Default
Plugin" -buildstyle Deployment GCC_VERSION="@GCC_VERSION@"
MACOSX_DEPLOYMENT_TARGET="@MACOSX_DEPLOYMENT_TARGET@" OTHER_CFLAGS="-DNDEBUG
-DTRIMMED"
=== BUILDING NATIVE TARGET Default Plugin  USING BUILD STYLE Deployment ===
undefined compiler specification com.apple.compilers.gcc.@GCC_VERSION@;
specification may be missing or target may be misconfigured
undefined compiler specification com.apple.compilers.gcc.@GCC_VERSION@;
specification may be missing or target may be misconfigured
** BUILD FAILED **
make[4]: *** [build-plugin] Error 1
make[3]: *** [libs] Error 2
make[2]: *** [tier_9] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

When building Camino with your patch I get this:

In file included from asdecode.cpp:40:
/usr/include/gcc/darwin/3.3/c++/cstdio:156: error: `vfscanf' not declared
/usr/include/gcc/darwin/3.3/c++/cstdio:165: error: `vfscanf' not declared
In file included from asdecode.cpp:41:
/usr/include/gcc/darwin/3.3/c++/cstdlib:138: error: `lldiv_t' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:139: error: `_Exit' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:148: error: syntax error before `(' 
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:149: error: syntax error before `.' 
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:149: error: syntax error before `.' 
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:152: error: syntax error before `(' 
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:153: error: syntax error before `.' 
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:153: error: syntax error before `.' 
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:155: error: `atoll' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:156: error: `strtof' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:159: error: `strtold' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:160: error: parse error before `}' 
   token
/usr/include/gcc/darwin/3.3/c++/cstdlib:164: error: `lldiv_t' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:165: error: `_Exit' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:168: error: `div' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:169: error: `lldiv' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:170: error: `atoll' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:171: error: `strtof' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:172: error: `strtoll' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:173: error: `strtoull' not declared
/usr/include/gcc/darwin/3.3/c++/cstdlib:174: error: `strtold' not declared
asdecode.cpp: In function `int main(int, char**)':
asdecode.cpp:114: warning: comparison between signed and unsigned integer 
   expressions
make[2]: *** [asdecode.o] Error 1
make[1]: *** [default] Error 2
make: *** [build] Error 2

Comment 134

[Josh Aas]

hmm... are you requiring the 10.3.9 sdk now?

Comment 135

[Frederic Bezies]

Well, SDK 10.3.9 seems to be required now. I built both firefox and thunderbird
using SDK 10.3.9 (I removed SDK 10.2.8 a few weeks ago).

My builds are fully working and based on :

- G4 1.42 Ghz / 512 Mb
- Tiger 10.4.1
- SDK 10.3.9
- gcc 3.3

Great work ;p

Comment 136

[Mike Pinkerton (not reading bugmail)]

the 10.2.8 SDK is required for building release builds. We must not enforce any
requirement for a 10.3.X SDK.

Comment 137

[Mark Mentovai]

Josh, run autoconf both in top-level and nsprpub and try again.  The
un-AC_SUBSTed @VAR@s in your Firefox build output are a dead giveaway.  The
Camino build output also indicates that you haven't run autoconf, although the
errors there are way more subtle.  You need autoconf 2.13 (not later) to test
the patch, the version supplied with the system in /usr/bin is too new and won't
work.  This is a Mozilla requirement, not one introduced by the patch.  At
commit time, you don't need to check in the regenerated configure scripts, they
will be automatically regenerated from the checked-in configure.ins.

I'm not requiring the 10.3.9 SDK, but without running autoconf, builds might
make more progress before failing if you're targeting 10.3.9.  Like pink said,
it's very important that we stick to 10.2.8 for the foreseeable future at the
very least.

I've been building against the 10.2.8 SDK all along (build host 10.4.1/Xcode 2)
as well as the 10.2.7 SDK (build host 10.3.9/Xcode 1.1) to make sure that
nothing breaks.

Comment 138

[Mark Mentovai]

Attachment: Backport of critical parts to aviary 1.0.x branch

I backported ph1a, ph1b, and ph2 to aviary_1.0.x.  These are only the critical
parts required to build under 10.4 while targeting an SDK.  This doesn't
include anything that has even a remote chance of breaking anything.  To use
it, run autoconf only in the top level, there aren't any nspr changes here.

I did test builds of Firefox with this patch on build host 10.4.1/Xcode 2.0/SDK
10.2.8 and build host 10.3.9/Xcode 1.1/SDK 10.2.7.

Mike, do you want anything like this for a stable Camino branch?

Comment 139

[Mark Mentovai]

Attachment: v13 (trunk) fixes a couple of Camino bugs introduced in v10

I just got a report of a couple of bugs in Camino building with the patch. 
Attempts to open links in new tabs or windows wouldn't work, and location bar
autocomplete was behaving erratically.	I traced the bug to missing
-fshort-wchar during the Camino build.	-fshort-wchar is set in OTHER_CFLAGS in
Camino.xcode/project.pbxproj, but it was being overridden by OTHER_CFLAGS
passed to xcodebuild on the command line.  This bug was introduced in v10 and
was present in ph4.

The only change in this patch is that OTHER_CFLAGS isn't passed to xcodebuild. 
Diff-to-diff diff for config/config.mk:
-+ifdef MOZ_DEBUG
-+PBBUILD_SETTINGS += OTHER_CFLAGS="$(MOZ_DEBUG_ENABLE_DEFS)"
-+else # MOZ_DEBUG
-+PBBUILD_SETTINGS += OTHER_CFLAGS="$(MOZ_DEBUG_DISABLE_DEFS)"
-+endif # MOZ_DEBUG

Also, the line number offsets for Camino.xcode/project.pbxproj have changed.

Since xcodebuild is already told to use the Deployment or Development style
depending on MOZ_DEBUG, this shouldn't have any real impact.

Thanks to James for notifying me of the problem.

Comment 140

[Mike Pinkerton (not reading bugmail)]

> Mike, do you want anything like this for a stable Camino branch?

hmmm. camino 0.8.x is checked out from MOZILLA_1_7_BRANCH. while i don't have
any plans to build that branch on tiger, or to release any further 0.8.x
releases, I guess in the future if i ever do, it might be far enough in the
future that all my machines are tiger. 

if it's easy to backport, i'd say go ahead, but don't waste too much time with it...

Comment 141

[Mark Mentovai]

Comment on attachment 184898 [details] [diff] [review]
v13 (trunk) fixes a couple of Camino bugs introduced in v10

Having trouble with Camino built on 10.3 due to the libmozz stuff being removed
from project.pbxproj.  The app launches but doesn't open any windows and
crashes on any attempt to do anything useful.  This isn't causing a problem for
10.4 build hosts.

Odd.

This may only affect non-static builds - I say that because I was testing
static builds more heavily before, and I didn't notice this until now.

Investigating alternatives - if the tree reopens before I've  whacked this, the
patch can land without the Camino.xcode/project.pbxproj modifications so that
we can at least get the core stuff out there, and finish work on Camino
separately.

Comment 142

[Robert Accettura [:raccettura]]

Got the following with the v13 patch applied when building on 10.4:

StandardURL.pp /cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp
/cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp: In member function
`nsresult nsStandardURL::BuildNormalizedSpec(const char*)':
../../../dist/include/string/nsTSubstring.h:502: error:
'nsCSubstring::nsCSubstring(const nsCSubstring&)' is protected
/cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp:497: error: within this context
../../../dist/include/string/nsTSubstring.h:502: error:
'nsCSubstring::nsCSubstring(const nsCSubstring&)' is protected
/cvsroot/mozilla/netwerk/base/src/nsStandardURL.cpp:497: error: within this context
make[5]: *** [nsStandardURL.o] Error 1
make[4]: *** [libs] Error 2
make[3]: *** [libs] Error 2
make[2]: *** [tier_9] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

Comment 143

[Brendan Eich [:brendan]]

Comment on attachment 184898 [details] [diff] [review]
v13 (trunk) fixes a couple of Camino bugs introduced in v10

a=me, for 1.8b3.

/be

Comment 144

[Josh Aas]

I am building Firefox now one more time with v13. If it builds and runs, I will check the patch in.
- I will not check in camino-specific code (mozilla/camino/)
- we may need to continue to build on 10.2, pending a discussion with chase and dbaron about 
tinderboxes. If my checkin breaks 10.2 building, the SeaMonkey tboxes will be horked. We should fix it 
ASAP but the risk is not enough to hold up the checkin according to chase.
- please continue discussing any build issues with this patch on this bug so I can track them

Comment 145

[Mark Mentovai]

Comment 142: Robert: You are using the gcc 4 that shipped with 10.4.  It's known
to be broken.  With the patch, a warning is printed at configure time about this
problem.  "sudo gcc_select 3.3" and try again.

Comment 143: Brendan: Thanks!

Comment 144: Josh: A checkin of v13 will almost certainly break 10.2 builds.  To
retain the ability to build on 10.2, we'll need to keep the pbproj dirs and
their contents around, so don't remove anything from cvs that comment 130 asks
you to remove.

Comment 146

[Mark Mentovai]

Attachment: Fix for probable Seamonkey tinderbox bustage

Apply this patch on top of v13 to hopefully restore buildability on 10.2.  I
don't have any more 10.2 systems, so I'm not positive, but this should do it.

This doesn't restore 10.2 buildability for Camino.  That ship sailed long ago.

This patch tests for the name of xcodebuild prior to doing a build for which
both pbbuild and xcode build files exist.  If it's called pbxbuild, it's
assumed to be Project Builder, pre-Xcode, and it's directed to the pbproj.  If
it's pbbuild, xcodebuild, or anything else, it's assumed to be Xcode, and it's
directed to the xcode project.	Josh, drop me a private e-mail when you land
v13 with or without this - I'll be "on the hook" and watch the tinderboxen as
well.

Comment 147

[Josh Aas]

Attachment: nspr parts of patch v13 (with autoconf updates) - most people should ignore this (checked in)

Comment 148

[Mark Mentovai]

Attachment: Better fix for Camino (ph5)

Apply this patch INSTEAD of the patches to camino/ from v13.  In other words,
this replaces the ph5 patch.  Compatible with both 10.3 and 10.4 build hosts.

The zlib workaround I came up with in v6 resulted in some broken Camino builds
on 10.3 build hosts.  Although the Camino mozconfig specified with-system-zlib,
the system zlib was not being used because it was too old, 1.1.3 on 10.3.9. 
Mozilla requires 1.2.2, so libmozz would be built and used.  10.4 includes zlib
1.2.2, so any build on 10.4 WOULD use the system zlib and libmozz wouldn't be
built.

Even selecting the 10.2 SDK on 10.4, configure would still wind up detecting
and using zlib 1.2.2, because the test program calls the zlibVersion() function
for its check and it winds up with the build host's zlib runtime version,
1.2.2.	If the test program might also checked the ZLIB_VERSION macro, brought
in from zlib.h, we wouldn't have this problem, but that's another bug for
another day (and one that will probably be forgotten).

This fully explains what pink saw in comment 20.

Dropping libmozz from Camino.xcode as I had done allowed builds on 10.4 at the
expense of 10.3.

I'm changing Camino's mozconfig to --without-system-zlib, since that's what the
effective setting was anyway, and because we don't want to be using zlib
runtimes older than 1.2.2 (pre-Tiger) even when the build host provides a newer
zlib.

Also restoring -lmozz where it had gotten dropped before in a premature checkin
(comment 72).  It's not strictly necessary because ld would reach the library
through the dylibs that depend on it, and it's debatable that it even belongs
there because as far as I know, nothing in Camino uses zlib directly.  It goes
back in because it was there before, it doesn't hurt anything, and it wouldn't
have gotten dropped but for the earlier solution in this bug.

Tested static build on 10.4 build host and non-static on 10.3, doing vice-versa
now.

Comment 149

[Mark Mentovai]

Attachment: up-to-date for configure.in

Now that the tree is open again, lots of other things landed this morning
before Josh had a chance to do the checkin.  This is the patch to top-level
configure.in  brought up to date.

Comment 150

[Josh Aas]

Attachment: security part of patch, most people should ignore this

Comment 151

[Mark Mentovai]

Attachment: Fix Seamonkey tinderbox (and other Panther users) build bustage

The proposal from last night wouldn't work because pbxbuild doesn't understand
-project.  This is better.

Comment 152

[Doug Turner (:dougt)]

Nelson -- 

Not sure about the history here, but Bob Relyea was asked to check in this patch:

https://bugzilla.mozilla.org/attachment.cgi?id=185043

to mozilla/security/coreconf.  Apparently the mozilla tree is busted without it.
 WTC was most likely involved in this discussion, but he currently is out of the
office.  

Comment 153

[Mark Mentovai]

Attachment: Panther fix (again) - proper variable name

Comment 154

[Robert Relyea]

'securty part, which most people should ignore;)" checked into NSS tip

Checking in Darwin.mk;
/cvsroot/mozilla/security/coreconf/Darwin.mk,v  <--  Darwin.mk
new revision: 1.10; previous revision: 1.9
done

I'll move the client tag only on this file to get Mozilla building again. NOTE:
before a mozilla product release, the client tag will have to be moved to an
official release of NSS, (currently the next release is slated to be 3.11).

bob

Comment 155

[Robert Relyea]

Client Tag has been updated.

makaila.sfbay.redhat.com(426) cvs log Darwin.mk | grep CLIENT
       {static dated CLIENT_TAGS removed. }
        NSS_CLIENT_TAG: 1.9
makaila.sfbay.redhat.com(428) cvs tag -F NSS_CLIENT_TAG Darwin.mk
T Darwin.mk
makaila.sfbay.redhat.com(429) cvs log Darwin.mk  | grep CLIENT
       {static dated CLIENT_TAGS removed. }
        NSS_CLIENT_TAG: 1.10

Comment 156

[Mark Mentovai]

Attachment: Panther fix (yet again) - out-of-order includes

Comment 157

[Mark Mentovai]

(In reply to comment #154)
> I'll move the client tag only on this file to get Mozilla building again. NOTE:
> before a mozilla product release, the client tag will have to be moved to an
> official release of NSS, (currently the next release is slated to be 3.11).

You didn't have to do that - the patch to security/coreconf/Darwin.mk was not
critical for building.  Feel free to adjust tags if necessary.

Comment 158

[Mark Mentovai]

All done here.  Thanks to everyone who helped with testing.

Comment 159

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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

Comment 160

[Mark Mentovai]

Note that if anyone decides to take the aviary 1.0.x patch, attachment 184775 [details] [diff] [review],
it will need to be augmented à la bug 296900 to work with Xcode 2.1.

Comment 161

[Julz]

> Note that if anyone decides to take the aviary 1.0.x patch, attachment 184775 [details] [diff] [review] [edit],
> it will need to be augmented à la bug 296900 to work with Xcode 2.1.

I just tried to compile Mozilla 1.7.5 with crypto and with the aviary 1.0.x patch, attachment 184775 [details] [diff] [review] on 
10.4 and with XCode 2.0 and here is what I got:

ld: Undefined symbols:
__Z21mime_crypto_stamped_pP10MimeObject
__Z21mime_set_crypto_stampP10MimeObjectii
make[5]: *** [libmime.dylib] Error 1
make[4]: *** [libs] Error 2
make[3]: *** [libs] Error 2
make[2]: *** [tier_97] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

Any advice?

Comment 162

[Mark Mentovai]

Attachment: Backport of critical parts to Aviary 1.0.x/Mozilla 1.7 branch

(In reply to comment #161)
Couldn't reproduce.  Be sure you're using gcc 3.3 and targeting a proper SDK. 
If possible, be sure that the identical configuration doesn't result in the
same error on 10.3.

(In reply to comment #160)
This contains the necessary portions of bug 296900 to allow building under
Xcode 2.1.  Patch prepared against Mozilla 1.7 this time, also applies on
Aviary 1.0.x.

Comment 163

[Mike Calmus]

These patches are working great for me. However, I am now having a related issue
with the CVS checkout. I have to remove the following two files each time before
I do a build (suite). I've even tried deleting the CVS directory to no avail.

cvs checkout: move away
mozilla/embedding/components/printingui/src/mac/printpde/PrintPDE.xcode/project.pbxproj;
it is in the way
C
mozilla/embedding/components/printingui/src/mac/printpde/PrintPDE.xcode/project.pbxproj
M mozilla/modules/plugin/samples/default/mac/DefaultPlugin.pbproj/project.pbxproj
cvs checkout: move away
mozilla/modules/plugin/samples/default/mac/DefaultPlugin.xcode/project.pbxproj;
it is in the way
C mozilla/modules/plugin/samples/default/mac/DefaultPlugin.xcode/project.pbxproj

Comment 164

[Mark Mentovai]

Anyone who had tested the patch will get that on cvs checkout now that the patch
landed.  Remove the source directories for printpde and defaultplugin and try
checking out again.

rm -rf /path/to/mozilla/embedding/components/printingui/src/mac/printpde
/path/to/mozilla/modules/plugin/samples/default/mac

If that doesn't work, try pulling a completely clean source directory, and if
you still have trouble, open a new bug.

Comment 165

[Julz]

(In reply to comment #162)
> (In reply to comment #161)
> Couldn't reproduce.  Be sure you're using gcc 3.3 and targeting a proper SDK. 
> If possible, be sure that the identical configuration doesn't result in the
> same error on 10.3.

Yes I have tried to target SDK 10.2.8 and SDK 10.3.0 same error...
I have no problem building 1.7.5 + crypto on 10.3

How can I compile a release version of Mozilla with crypto on Tiger? (I have no problem building 1.7.5 no 
crypto)

Comment 166

[Neil Lee [:neilio]]

I'm sorry if this is a total newbie / OT question here, but which patch am I supposed to apply now to build 
Firefox 1.0.6 on Mac OS X 10.4? The incredible number of patches here is a bit bewildering...

Comment 167

[Josh Aas]

You don't need a patch - you need 2 things...

1) use "sudo gcc_select 3.3" to select gcc 3.3 instead of 4. You can't build the
1.0.6 branch with gcc 4 AFAIK.
2) build against the Mac OS X 10.2.8 SDK (add a line to your .mozconfig file)

Comment 168

[Josh Aas]

never mind - you can't build the branch on 10.4 without some patches that don't
exist. sorry.

Comment 169

[Neil Lee [:neilio]]

(In reply to comment #168)
> never mind - you can't build the branch on 10.4 without some patches that don't
> exist. sorry.

Is this a new development specific to building 1.0.6? I built 1.0.5 on Mac OS X 10.4 after applying this 
patch, running autoconf 2.1.3, and using gcc 3.3 with no problems.

Comment 170

[Mark Mentovai]

You want attachment 185940 [details] [diff] [review] to this bug for the 1.0.x/1.7 branch.  You need to
run autoconf (must be autoconf 2.13) and you're limited to using gcc 3.3 with
SDK 10.2.8.  If it doesn't work, open a new bug or follow another support
channel.  Let's try to keep the bugspam down here, 'k?

Comment 171

[Asa Dotzler [:asa]]

Comment on attachment 185940 [details] [diff] [review]
Backport of critical parts to Aviary 1.0.x/Mozilla 1.7 branch

1.0.5 and 1.7.9 have already shipped; unsetting approval requests.