NSS community/maintainer types, I've been doing some hacking to sort out remaining issues with getting 32-bit build support on OS X 10.6, allowing for universal builds, and I wanted to make sure I was headed in the right direction, such that what I'm doing might be acceptable as patches. I've been working with the 3.12.9 build and checking against the CVS head to see what's already been patched in the Makefile infrastructure. Here's what I've scoped out thus far:
1) coreconf/Darwin.mk needs a few changes, mostly to make sure that, similar to
the "-arch x86_64" appended to CC for 64-bit builds, "-arch i386" is appended
for 32-bit builds. I've compared the behaviour under 10.6 to what I see in the
logs on the Tinderbox builds, and it looks to me that the gcc for Xcode 3.1.X
emits 32-bit binaries by default, whereas the behaviour changes on 10.6/Xcode
3.2.X to default to 64-bit. It shouldn't break anything to be explicit in both
cases.
2) nsinstall.c needs code changes to be able to call out to lipo for
installation of binaries, which should also require an additional option ("-u")
to use lipo instead of doing the copy operations itself
3) the above would require further corresponding changes to the Makefile
infrastructure (chiefly coreconf/rules.mk) to allow nsinstall invocations to be
changed for appropriate targets (LIBRARY, SHARED_LIBRARY, PROGRAM)
4) I'm not entirely clean on why NSDISTMODE defaults to relative symlinks,
except perhaps it's easiest to have that as a default behaviour in a dev
environment, something that seems like it ought to be documented
Although it's not strictly related, one sticky wicket seems to be dealing with
having NSPR already built in a separate tree. The ns_build_all target assumes
that it needs to attend to this, and although it's easy enough to work out what
targets need to be called, the workaround is somewhat fragile. It would seem
preferable if something like defining NSPR_LIB_DIR when nss/Makfile is first
invoked with the ns_build_all target would change the NSPR pre-req
(build_nspr), rather than having people work out which steps to subtract and
performing these steps. Also: it seems like setting NSPR_LIB_DIR should change
LDOPTS in coreconf/locations.mk, much as changing NSPR_INCLUDE_DIR changes
INCLUDES.
This is a first stab, nothing exhaustive, and I'll warn as well that I've been
looking at NSS (thus only the mozilla/security tree) in isolation, so I don't
properly appreciate any issue that may arise from using this with the larger
Mozilla build process. I'm happy to provide all the patches for review, but
first I wanted to get a reasonable amount of context and buy-in from the
maintainers. There's plenty of stuff out there that really wants to have a
universal build including both 32-bit and 64-bit x86 NSS to port to OS X, so
I'd quite like to sort this out one way or other. There was a thread on this
subject earlier this year, and my conclusion from that was that there was
general support amongst the developers for sorting this out.
Cheers,
Bayard
PGP.sig
Description: This is a digitally signed message part
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
