363092 - cannot build with native SDK on Mac OS X 10.5

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Josh Aas]

It is not possible to build on Mac OS X 10.5 with the native headers (you have to use an SDK).

Comment 1

[Josh Aas]

Among other problems it looks like Apple messed up their kerberos library headers (they include a file that doesn't exist). We can't really work around that except to disable the auth extension. I have filed a bug with Apple.

Comment 2

[Josh Aas]

Attachment: fix v1.0

This will allow building on 10.5 without an SDK.

You have to also add "ac_add_options --disable-negotiateauth" to your mozconfig - Mac OS X kerberos is broken in 10.5 builds right now, I have filed a bug with Apple.

I have filed a bug with Apple about updating their MoreFilesX code to work on 10.5. Once they have done so we can simply update the copy of MoreFilesX that we have in our tree. In the mean time we can simply ifdef out the conflicting function, we don't use it.

Comment 3

[Josh Aas]

Oh yeah - thanks to Colin Barrett for figuring out the pthreads conflict part of this!

Comment 4

[Josh Aas]

Attachment: fix v1.1

Better yet, just kill the pthread ifdef because we've had pthread_kill since 10.2.

Comment 5

[Wan-Teh Chang]

Josh, do we not have to support Mac OS X 10.2 now?  What's
the pthread conflict?

Comment 6

[Josh Aas]

10.2 has pthread_kill - we don't support < 10.2 on the branch or the trunk.

Comment 7

[Wan-Teh Chang]

Comment on attachment 247863 [details] [diff] [review]
fix v1.1

r=wtc.  Josh, could you post the compiler error message if we don't delete this?

>-/*
>- * These platforms don't have pthread_kill()
>- */
>-#if defined(DARWIN)
>-#define pthread_kill(thread, sig) ENOSYS
>-#endif

Comment 8

[Colin Barrett [:cbarrett]]

Here's the specific error.

gcc -o prlink.o -c      -pipe -Wmost -fno-common -no-cpp-precomp -g -fPIC  -UNDEBUG -DDEBUG_ramoth4 -DMOZILLA_CLIENT=1 -DDEBUG=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DXP_UNIX=1 -DDARWIN=1 -DHAVE_BSD_FLOCK=1 -Di386=1 -DXP_MACOSX=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1  -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_ -I/Users/ramoth4/Projects/Mozilla/mozilla/obj-i386-apple-darwin9.0.0d4/dist/include/nspr -I/Users/ramoth4/Projects/Mozilla/mozilla/nsprpub/pr/include -I/Users/ramoth4/Projects/Mozilla/mozilla/nsprpub/pr/include/private -I/Developer/Headers/FlatCarbon  /Users/ramoth4/Projects/Mozilla/mozilla/nsprpub/pr/src/linking/prlink.c
In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:21,
                 from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:20,
                 from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21,
                 from /Developer/Headers/FlatCarbon/CodeFragments.h:1,
                 from /Users/ramoth4/Projects/Mozilla/mozilla/nsprpub/pr/src/linking/prlink.c:48:
/usr/include/signal.h:84: error: syntax error before numeric constant


Looking at the .i, the specific line that gets complained about ends up looking like:

int 78;

(78 being the value of ENOSYS)

Comment 9

[Wan-Teh Chang]

Attachment: NSPR workaround

Thank you.  Could you try this NSPR patch?  After applying this
patch, do "make clean; make" in nsprpub.

I will still remove the problematic code, but if this workaround
works, I may use it on older NSPR branches.

Comment 10

[Josh Aas]

I landed the xpcom changes I made, wtc is going to have to do the nspr changes I think.

The nspr workaround you posted does seem to work, but can you explain why it does?

Comment 11

[Wan-Teh Chang]

Thank you for testing my workaround.

NSPR includes the relevant headers in this order:

#include <pthread.h>

#include "pth.h"

#include <signal.h>

I suspect that pthread_kill is declared in <pthread.h> on
Mac OS X 10.2-10.4, so we have:

pthread.h: int pthread_kill(pthread_t thread, int sig);

pth.h:     #define pthread_kill(thread, sig) ENOSYS

This compiles just fine.  The compiler error message that
Colin provided in comment 8 shows that pthread_kill is declared
in <signal.h> on Mac OS X 10.5, so we have:

pth.h:     #define pthread_kill(thread, sig) ENOSYS

signal.h:  int pthread_kill(pthread_t thread, int sig);

This is a compilation error because the macro will be expanded
in the function declaration.  My workaround is a trick I used
before.  It takes advantage of the "include once" feature of
header files -- we include the problematic header first as
a preventive measure:

#include <pthread.h>

pth.h: #include <signal.h>
pth.h: #define pthread_kill(thread, sig) ENOSYS

#include <signal.h>  // now a no-op

Note: since pthread_kill sends a signal to a thread, it makes
sense to declare this function in either <pthread.h> or <signal.h>.
I just checked Single Unix Specification version 3.  It says
pthread_kill should be declared in <signal.h>.  So I guess Apple
is trying to conform to the Unix standard by moving the declaration
from <pthread.h> to <signal.h>.

Comment 12

[Wan-Teh Chang]

Attachment: NSPR configure.in patch

Right now NSPR's default MACOSX_DEPLOYMENT_TARGET is still 10.1
for ppc.  This patch changes it to 10.2.

Josh, could you also review my NSPR workaround (for older NSPR
branches)?  Thanks.

Comment 13

[Wan-Teh Chang]

I checked in the NSPR configure.in patch and the NSPR part of
Josh's fix v1.1 on the NSPR trunk (NSPR 4.7) and the
NSPRPUB_PRE_4_2_CLIENT_BRANCH for the Mozilla trunk (1.9 Alpha 2).

Comment 14

[Josh Aas]

Apple has fixed the kerberos bug in their latest build, no need to turn that off any more to build with the native SDK on 10.5.