509262 - NSPR configure still defines minimum Mac OS X version as 10.2 on PPC

Status: RESOLVED FIXED

(NSPR :: NSPR, defect)

Description

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

While looking at NSPR's configure.in from wtc's link in bug 504523 comment 31, I noticed the file has two places where it mentions a default minimum OS of Mac OS X 10.2 for PPC:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/configure.in&rev=HEAD&mark=265-269#258

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/configure.in&rev=HEAD&mark=1026-1029#982

As we've seen in bug 504523, NSPR >= NSPR_4_7_2_BETA_1 (at the latest) is no longer compatible with Mac OS X 10.2 or 10.3 (revision 1.240 of configure.in introduced the build failure with the 10.2.8 SDK seen in bug 504523, and it slightly predates the prsystem.c failure that breaks 10.3 support).

I don't understand the code in question well enough, and haven't tried compiling stand-alone NSPRs with and without SDKs and running them on 10.2 (which I don't have access to), but I believe the fact that current NSPR versions won't build against the 10.2.8 SDK means they will not run on 10.2 at all (and they certainly won't build on 10.2 without an SDK, since the SDK mirrors what is available on the OS release with the corresponding version number).

I believe both of these places in configure.in need to be updated to have a 10.4 minimum for PPC (unless there are #ifdef-type code changes in progress to restore compatibility with 10.2 and 10.3).

Note that bug 363092 bumped these to 10.2 when dropping 10.1 support, but neither bug 370766 nor bug 454878 bumped them to 10.3 and 10.4, respectively, when making changes incompatible with/dropping support for 10.2 and 10.3.

Comment 1

[Wan-Teh Chang]

Attachment: Restore Mac OS X 10.2 and 10.3 support

I am not planning to check this in on the NSPR trunk
for NSPR 4.8.x.

Ted: please review the NSPR configure test for socklen_t.
I based it on the HAVE_INT64_T test in Mozilla's configure.in.

Josh: please review the prsystem.c change.

I checked this in on the NSPR_4_7_BRANCH for NSPR 4.7.6.

Checking in configure;
/cvsroot/mozilla/nsprpub/configure,v  <--  configure
new revision: 1.242.2.2; previous revision: 1.242.2.1
done
Checking in configure.in;
/cvsroot/mozilla/nsprpub/configure.in,v  <--  configure.in
new revision: 1.246.2.2; previous revision: 1.246.2.1
done
Checking in pr/src/misc/prsystem.c;
/cvsroot/mozilla/nsprpub/pr/src/misc/prsystem.c,v  <--  prsystem.c
new revision: 3.31.4.1; previous revision: 3.31
done

Comment 2

[Wan-Teh Chang]

Attachment: Unused patch (do not check in)

I attached this patch for reference only.  I don't plan to check this in.
This patch contains two independent changes.

1. By switching from System V semaphores to POSIX semaphores, I
was able to make some (or all) of NSPR's semaphore tests pass on
Mac OS X 10.3.  This change does not help on Mac OS X 10.2 though.

This change requires more research and testing.  Since Mozilla is not
using NSPR semaphores (PRSem), there is little need for this change.

2. The socklen_t type is available on Mac OS X 10.3 or later.  So we
can define HAVE_SOCKLEN_T by testing Mac OS X version.  I decided
to use a configure test in the end, but I also implemented the Mac
OS X version test and verified that it works.