58799 - Building Mozilla from source problems on MacOS X

Status: RESOLVED DUPLICATE of bug 75653

(SeaMonkey :: Build Config, defect, P3)

Description

[handel]

1) autoconf needs to be updated to automatically recognize MacOS X
(ie. maybe incorporate /usr/libexec/config.* from a MacOS X system)

2) Turn Rhapsody.mk into Darwin.mk

3)
ifeq ($(OS_ARCH),Rhapsody)
MDCPUCFG_H = _rhapsody.cfg
endif

isn't getting picked up in nsprpub/pr/include/md/Makefile

Comment 1

[cls]

wtc, this will require a couple of NSPR changes.  Landing a more recent
config.sub & config.guess to detect new architectures for starters.  I'm not
sure about the Rhapsody/Darwin substitution though.

Comment 2

[Wan-Teh Chang]

The Rhapsody->Darwin substitution can be done on the tip.
It is not worth fixing on the existing release branches
because I consider it a cosmetic change.

Landing a more recent config.sub & config.guess is fine.

Comment 3

[Fabian Guisset]

Not a blocker since this has no milestone assigned and has not been touched in
two monthes. Getting it off the blocker radar. THanks.

Comment 4

[Dave Alverson]

Attachment: nspr patchs for config and make files

Comment 5

[Dave Alverson]

Attachment: new nsprpub/config/Darwin.mk

Comment 6

[Dave Alverson]

Attachment: new nsprpub/pr/include/md/_darwin.cfg

Comment 7

[Dave Alverson]

Attachment: new nsprpub/pr/include/md/_darwin.h

Comment 8

[Dave Alverson]

Attachment: new nsprpub/pr/src/md/unix/darwin.c

Comment 9

[Dave Alverson]

I think these patches handle most of nspr-land.  I doesn't look like they should 
affect any other platforms.  I havent seen a g++ dir (spec'd in Darwin.mk) but it 
builds ok.  I think theres a c++ dir under the System.framework that might be a 
default include path.

Comment 10

[Jon Granrose]

changing QA contact to jj.

Comment 11

[Dave Alverson]

I found some more changes in nsprpub that were needed and am trying to get the 
test programs to run.  accept, acceptread and alarm all hang (I didnt try many 
others).  There are known deficiencies in apples pthreads impl (see http://
www.opensource.apple.com/bugs/X/Libraries/2542757.html).  In Darwin.mk I changed 
to IMPL_STRATEGY   = _EMU and  DEFINES += -D_PR_LOCAL_THREADS_ONLY and those 3 
tests no longer hang.  acceptread did give some weird errors in later tests.  

Comment 12

[Wan-Teh Chang]

We should try to use native threads.  Using NSPR local
threads has its own problems.

None of the bugs reported in
www.opensource.apple.com/bugs/X/Libraries/2542757.html
really affect NSPR.  (I reported some of them to Apple
too.)

Comment 13

[Dave Alverson]

I just noticed the head of NSPR handles Darwin by mapping OS_ARCH to Rhapsody in
arch.mk.  This is not in NSPRPUB_CLIENT_BRANCH yet, AFAIK.  So all of my 1/08
patches are moot.  But what is the strategy for the rest of mozilla?  I don't
see any mechanism like arch.mk for the main mozilla Makefile.  Should Darwin
cases be added to Makefiles where needed, or some way of mapping to Rhapsody?

Comment 14

[Dave Alverson]

Duh.  In the top configure.in, I have a darwin case that's a copy of the
rhapsody case.  I just added these lines to the darwin case: 
OS_ARCH=Rhapsody
OS_TARGET=Rhapsody
I am trying this now.  On compile lines I am seeing -D OSTYPE=Darwin1.2 but I'm
not sure if that matters.

Comment 15

[cls]

Setting milestones to Future.

Comment 16

[Dave Alverson]

Attachment: Fix nspr autoconf for Rhapsody/Darwin/MacOSX

Comment 17

[Steve Dagley]

Chris, can we close this bug with all the recent work that's gone into the
mach-o build?

Comment 18

[cls]

*** This bug has been marked as a duplicate of 75653 ***