Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On 29.3.11 20:21, Mark Mentovai wrote: Wan-Teh and I discussed adding a new header to handle this problem, security/nss/lib/freebl/blconfig.h, that could be #included as needed where definitions of macros like NSS_X86 and NSS_USE_64 are significant. This could be structured like #ifdef DARWIN #ifdef __i386__ #define NSS_X86 #define NSS_X86_OR_X64 #endif /* __i386__ */ #ifdef __x86_64__ #define NSS_X64 #define NSS_X86_OR_X64 #endif /* __x86_64__ */ #ifdef __LP64__ #define NSS_USE_64 #endif /* __LP64__ */ #endif /* DARWIN */ and definitions of these macros could be removed from security/nss/lib/ freebl/Makefile when building for Darwin, along the lines of ifneq ($(OS_TARGET),Darwin) ... endif Sounds good. security/nss/lib/jar is currently the other place which also depends on the NSS_X* macros, i.e. it should be a header file which can be used by files outside freebl, too. (CPU_ARCH=dummy is kind of a hack, currently - it's only purpose is to prevent coreconf from applying the x86 related settings in the ifeq... CPU_ARCH block. It will add -Dppc to the CC command, but this doesn't do any harm, I think. Note that the backslashes are required to protect the following blanks.) For my purposes, when I’m working with single-pass universal builds and am expected to provide a CPU specification at some level that’s too general to actually know the target CPU, I usually use “mac.” The command line I provided in my earlier message was just meant as a proof of concept - under the assumption that you use NSS trunk as-is (i.e., you can use it right now w/o touching any files in the tree). When adding support for universal binaries to Darwin.mk, we don't necessarily have to use CPU_ARCH to specify the options a universal build, I think. A separate option, let's say something like NSS_OSX_MULTIARCH) could be used to specify the list of architectures to compile (and would be handled in Darwin.mk in the way proposed by Bayard). If specified, it would unset CPU_ARCH at the same time. Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On 30.3.11 02:52, Wan-Teh Chang wrote: Mandating Apple compilers is fine. Until one or two years ago, NSPR and NSS were using the -Wmost flag, which is an Apple extension. I was the one who noticed the problem. That's strong evidence that no one else had tried to compile NSPR or NSS on the Mac with non-Apple GCC. Note that this is also true for the -arch option (and -arch x86_64 was added to Darwin.mk two years ago with https://bugzilla.mozilla.org/show_bug.cgi?id=469738, and I guess nobody complained about build failures with USE_64=1). But we should use -Xarch_arch only if it offers a simpler solution than defining arch-specific macros in lib/freebl/blconfig.h. Agreed. Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On Wed, Mar 30, 2011 at 6:45 AM, Kaspar Brand m...@velox.ch wrote: Sounds good. security/nss/lib/jar is currently the other place which also depends on the NSS_X* macros, i.e. it should be a header file which can be used by files outside freebl, too. I see. security/nss/lib/util/secport.h is a header where we can define these NSS_* macros. It already defines a few such macros: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/secport.hrev=1.23mark=53-74#49 The only problem is that secport.h is a public header, so those NSS_* macro definitions will also be seen by NSS customers. Another option is to fix security/nss/lib/jar so that it doesn't use the NSS_X86_OR_X64 macro. lib/jar is only used by the NSS command-line tools modutil and signutil, so it isn't important to rely on x86/x86_64 processors' ability to do unaligned memory access. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On 30.03.2011 19:19, Wan-Teh Chang wrote: Another option is to fix security/nss/lib/jar so that it doesn't use the NSS_X86_OR_X64 macro. lib/jar is only used by the NSS command-line tools modutil and signutil, so it isn't important to rely on x86/x86_64 processors' ability to do unaligned memory access. Right, I had another look at libjar, and there's only one place in the code which relies on NSS_X86_OR_X64, in jarfile.c: #ifdef NSS_X86_OR_X64 #define x86ShortToUint32(ii) ((const PRUint32)*((const PRUint16 *)(ii))) #define x86LongToUint32(ii)(*(const PRUint32 *)(ii)) #else static PRUint32 x86ShortToUint32(const void *ii); static PRUint32 x86LongToUint32(const void *ll); #endif (later on, there are implementations of x86ShortToUint32 and x86LongToUint32 which simulate an x86 (little endian, unaligned) uint fetch from any address) If we agree that we can sacrifice this optimization for x86 in jarfile.c, then it seems fairly straightforward to nuke NSS_X86_OR_X64 from libjar, so that there would be no further obstacle to using freebl/blconfig.h (which, IMO, seems preferrable to putting things into the public secport.h header). Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
Kaspar Brand wrote: On 24.1.11 22:08, Wan-Teh Chang wrote: It is also possible to build for two arches in one pass, for example, gcc -arch i386 -arch x86_64. GCC still compiles each file twice in this method. This method does have one limitation -- you can't define an arch-specific macro, such as -Di386 or -DNSS_X64 on the compiler command line. That's not completely true, as I found out in the meantime. There is a solution to this problem - the Xarch option (Apple-specific gcc extension): I would avoid this. -Xarch_arch is implemented as an Apple GCC driverdriver option and isn’t available in mainline GCC or even the Apple GCC’s CPU-specific frontends (such as i686-apple-darwin10- gcc-4.2.1). -Xarch_arch would allow things to work with Apple GCC and would even enable single-pass universal builds, but would ruin things for users of non-Apple GCC. NSPR and NSS have striven to be flexible with respect to build configurations in the past. I’d be surprised if either project were now willing to mandate that Apple GCC (or some other Apple-supplied compiler) would be the only compiler that could be used to target Mac OS X or Darwin. Wan-Teh and I discussed adding a new header to handle this problem, security/nss/lib/freebl/blconfig.h, that could be #included as needed where definitions of macros like NSS_X86 and NSS_USE_64 are significant. This could be structured like #ifdef DARWIN #ifdef __i386__ #define NSS_X86 #define NSS_X86_OR_X64 #endif /* __i386__ */ #ifdef __x86_64__ #define NSS_X64 #define NSS_X86_OR_X64 #endif /* __x86_64__ */ #ifdef __LP64__ #define NSS_USE_64 #endif /* __LP64__ */ #endif /* DARWIN */ and definitions of these macros could be removed from security/nss/lib/ freebl/Makefile when building for Darwin, along the lines of ifneq ($(OS_TARGET),Darwin) ... endif (CPU_ARCH=dummy is kind of a hack, currently - it's only purpose is to prevent coreconf from applying the x86 related settings in the ifeq... CPU_ARCH block. It will add -Dppc to the CC command, but this doesn't do any harm, I think. Note that the backslashes are required to protect the following blanks.) For my purposes, when I’m working with single-pass universal builds and am expected to provide a CPU specification at some level that’s too general to actually know the target CPU, I usually use “mac.” -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On Tue, Mar 29, 2011 at 11:21 AM, Mark Mentovai m...@chromium.org wrote: I would avoid this. -Xarch_arch is implemented as an Apple GCC driverdriver option and isn’t available in mainline GCC or even the Apple GCC’s CPU-specific frontends (such as i686-apple-darwin10- gcc-4.2.1). -Xarch_arch would allow things to work with Apple GCC and would even enable single-pass universal builds, but would ruin things for users of non-Apple GCC. NSPR and NSS have striven to be flexible with respect to build configurations in the past. I’d be surprised if either project were now willing to mandate that Apple GCC (or some other Apple-supplied compiler) would be the only compiler that could be used to target Mac OS X or Darwin. Mandating Apple compilers is fine. Until one or two years ago, NSPR and NSS were using the -Wmost flag, which is an Apple extension. I was the one who noticed the problem. That's strong evidence that no one else had tried to compile NSPR or NSS on the Mac with non-Apple GCC. But we should use -Xarch_arch only if it offers a simpler solution than defining arch-specific macros in lib/freebl/blconfig.h. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On 22.1.11 13:58, Kaspar Brand wrote: On 20.1.11 20:57, Robert Relyea wrote: If you have the proper changes to coreconf to produce 32 bits on a Mac 64 bit system, we would certainly be interested. I think something like the attached patches (not only for NSS, but also for NSPR) should do the trick. Adding -arch options shouldn't hurt for older OS X versions. I just realized that my message from 22 January never made it to Google Groups (most likely due to the presence of attachments), so I'm repeating some information here. [1] The patches previously attached have now been filed as https://bugzilla.mozilla.org/show_bug.cgi?id=645460 (NSS) and https://bugzilla.mozilla.org/show_bug.cgi?id=645459 (NSPR). Building universal binaries for NSS in a single step, on the other hand, is something which doesn't work properly yet. In theory, this could be achieved by setting CC=gcc -arch x86_64 -arch i386 with the make command (which instructs GCC to compile separate versions and assemble them with lipo afterwards), but this will currently fail at drbg.c: gcc -arch x86_64 -arch i386 -o Darwin10.6.0_OPT.OBJ/Darwin_SINGLE_SHLIB/drbg.o -c -O2 -fPIC -Di386 -Wall -fno-common -pipe -DDARWIN -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\dylib\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DMP_API_COMPATIBLE -I../../../../dist/Darwin10.6.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl drbg.c drbg.c: In function 'RNG_RandomUpdate': drbg.c:516: error: size of array 'arg' is negative Looking at the current logic in drgb.c #if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) !defined(NS_PTR_LE_32)) PR_STATIC_ASSERT(sizeof(size_t) 4); #else PR_STATIC_ASSERT(sizeof(size_t) = 4); #endif this is due to GCC trying to compile for x86_64, but without NSS_USE_64 being set. Maybe this could be addressed by modifications to drbg.c? (Adding USE_64=1 to the make command won't help, because that makes the i386 part fail.) On 24.1.11 22:08, Wan-Teh Chang wrote: It is also possible to build for two arches in one pass, for example, gcc -arch i386 -arch x86_64. GCC still compiles each file twice in this method. This method does have one limitation -- you can't define an arch-specific macro, such as -Di386 or -DNSS_X64 on the compiler command line. That's not completely true, as I found out in the meantime. There is a solution to this problem - the Xarch option (Apple-specific gcc extension): -Xarch_arch option Apply option to the command line for architecture arch. This is useful for specifying an option that should only apply to one architecture when building a universal binary. (APPLE ONLY) With the following make command, it's actually possible to compile 3-architecture universal binaries in a single step: make nss_build_all CC=gcc -arch x86_64 -Xarch_x86_64 -DNSS_USE_64\ -DNSS_X64\ -DNSS_X86_OR_X64 -arch i386 -Xarch_i386 -DNSS_X86\ -DNSS_X86_OR_X64 -arch ppc BUILD_OPT=1 NSS_ENABLE_ECC=1 CPU_ARCH=dummy (CPU_ARCH=dummy is kind of a hack, currently - it's only purpose is to prevent coreconf from applying the x86 related settings in the ifeq... CPU_ARCH block. It will add -Dppc to the CC command, but this doesn't do any harm, I think. Note that the backslashes are required to protect the following blanks.) This will give you fat binaries in the respective dist/ subtree: $ file dist/Darwin10.7.0_OPT.OBJ/bin/certutil dist/Darwin10.7.0_OPT.OBJ/bin/certutil: Mach-O universal binary with 3 architectures dist/Darwin10.7.0_OPT.OBJ/bin/certutil (for architecture x86_64): Mach-O 64-bit executable x86_64 dist/Darwin10.7.0_OPT.OBJ/bin/certutil (for architecture i386): Mach-O executable i386 dist/Darwin10.7.0_OPT.OBJ/bin/certutil (for architecture ppc7400):Mach-O executable ppc Depending on how important support for universal build is considered, this could be added as a further option to Darwin.mk? Kaspar [1] See http://thread.gmane.org/gmane.comp.mozilla.crypto/15825/focus=15831 for an archived copy -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
I was looking at how this might be rolled in as something like a
pseudo-architecture (e.g. darwin-universal-x86+x64+ppc64) to roll in the
various flags for different universal targets, and I think there may be some
significant side-effects. I haven't dug in to compare how it changes the
operations under Makefile control, but eyeballing it tells me it breaks
subsequent references to CPU_ARCH outside of coreconf, mostly the stuff in the
freebl Makefile that decide when to use assembler code, which I assume to exist
for things like on-chip crypto support such as AES-NI. These branches look to
be OS_TARGET-specific at the top level and currently absent any provision for
Darwin, but what I'd ask is, if you wanted to be able to extend these
optimisations to the platform, how would you do it with a non-iterative build?
As for how to roll the below into Darwin.mk, I haven't tested it, but I'd
suggest adding pseudo-platform support to Darwin.mk before or after the block
that current starts at line 52:
ifneq (,$(findstring darwin-universal,${CPU_ARCH}))
$(warning ${CPU_ARCH} is a universal target with experimental support.
Cross-check settings against new Makefiles, and do not use with a non-Apple
gcc. Some architectures may no longer be supported by later Apple releases of
gcc.)
UNIVERSAL_ARCHES = x64 x86 ppc64
ARCHES = $(subst +, ,$(patsubst darwin-universal-%,%,${CPU_ARCH}))
UNKNOWN_ARCHES = $(filter-out ${UNIV_ARCHES},${ARCHES})
ifneq (,${UNKNOWN_ARCHES})
$(error Do not know how to make universal arches ${UNKNOWN_ARCHES})
ifneq (,$(filter x86,${ARCHES}))
CC += -arch i386
OS_REL_CFLAGS += -Xarch_i386 -DNSS_X86 \
-Xarch_i386 -DNSS_X86_OR_X64
endif
ifneq (,$(filter x64,${ARCHES}))
CC += -arch x86_64
OS_REL_CFLAGS += -Xarch_x86_64 -DNSS_USE_64 \
-Xarch_x86_64 -DNSS_X64 \
-Xarch_X86_OR_X64 -DNSS_X86_OR_X64
endif
ifneq (,$(filter ppc64,${ARCHES}))
CC += -arch ppc64
OS_REL_CFLAGS += -Xarch_ppc64 -Dppc
endif
endif
On 27 Mar 2011, at 09:11, Kaspar Brand wrote:
On 24.1.11 22:08, Wan-Teh Chang wrote:
It is also possible to build for two arches in one pass, for example,
gcc -arch i386 -arch x86_64. GCC still compiles each file twice in
this method. This method does have one limitation -- you can't define
an arch-specific macro, such as -Di386 or -DNSS_X64 on the compiler
command line.
That's not completely true, as I found out in the meantime. There is a
solution to this problem - the Xarch option (Apple-specific gcc
extension):
-Xarch_arch option
Apply option to the command line for architecture arch. This is
useful for specifying an option that should only apply to one
architecture when building a universal binary. (APPLE ONLY)
With the following make command, it's actually possible to compile
3-architecture universal binaries in a single step:
make nss_build_all CC=gcc -arch x86_64 -Xarch_x86_64 -DNSS_USE_64\
-DNSS_X64\ -DNSS_X86_OR_X64 -arch i386 -Xarch_i386 -DNSS_X86\
-DNSS_X86_OR_X64 -arch ppc BUILD_OPT=1 NSS_ENABLE_ECC=1 CPU_ARCH=dummy
(CPU_ARCH=dummy is kind of a hack, currently - it's only purpose is to
prevent coreconf from applying the x86 related settings in the ifeq...
CPU_ARCH block. It will add -Dppc to the CC command, but this doesn't do
any harm, I think. Note that the backslashes are required to protect the
following blanks.)
This will give you fat binaries in the respective dist/ subtree:
$ file dist/Darwin10.7.0_OPT.OBJ/bin/certutil
dist/Darwin10.7.0_OPT.OBJ/bin/certutil: Mach-O universal binary with 3
architectures
dist/Darwin10.7.0_OPT.OBJ/bin/certutil (for architecture x86_64):Mach-O
64-bit executable x86_64
dist/Darwin10.7.0_OPT.OBJ/bin/certutil (for architecture i386): Mach-O
executable i386
dist/Darwin10.7.0_OPT.OBJ/bin/certutil (for architecture ppc7400): Mach-O
executable ppc
Depending on how important support for universal build is considered,
this could be added as a further option to Darwin.mk?
Kaspar
[1] See
http://thread.gmane.org/gmane.comp.mozilla.crypto/15825/focus=15831 for
an archived copy
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
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
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On 01/22/2011 04:58 AM, Kaspar Brand wrote: On 20.1.11 20:57, Robert Relyea wrote: On 01/19/2011 10:36 PM, Kaspar Brand wrote: That's certainly doable, but I don't think the NSS build system has support for building universal binaries (you'd have to fiddle with lipo yourself). I think it depends on what the Mac compiler kicks out. On Windows or Linux, the non-64 bit builds automatically set the compiler to produce 32-bit binaries unless the USE_64 is set. By default, GCC on OS X does not create universal binaries. Starting with 10.6 (Snow Leopard), the default changed from 32 to 64 bit, though. My guess is that no one has set the compiler flags correct for building 32-bit binaries on Mac 64. That's a perfect guess, yes: If you have the proper changes to coreconf to produce 32 bits on a Mac 64 bit system, we would certainly be interested. I think something like the attached patches (not only for NSS, but also for NSPR) should do the trick. Adding -arch options shouldn't hurt for older OS X versions. Building universal binaries for NSS in a single step, on the other hand, is something which doesn't work properly yet. In theory, this could be achieved by setting CC=gcc -arch x86_64 -arch i386 with the make command (which instructs GCC to compile separate versions and assemble them with lipo afterwards), but this will currently fail at drbg.c: gcc -arch x86_64 -arch i386 -o Darwin10.6.0_OPT.OBJ/Darwin_SINGLE_SHLIB/drbg.o -c -O2 -fPIC -Di386 -Wall -fno-common -pipe -DDARWIN -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\dylib\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DMP_API_COMPATIBLE -I../../../../dist/Darwin10.6.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl drbg.c drbg.c: In function 'RNG_RandomUpdate': drbg.c:516: error: size of array 'arg' is negative Looking at the current logic in drgb.c #if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) !defined(NS_PTR_LE_32)) PR_STATIC_ASSERT(sizeof(size_t) 4); #else PR_STATIC_ASSERT(sizeof(size_t) = 4); #endif this is due to GCC trying to compile for x86_64, but without NSS_USE_64 being set. Maybe this could be addressed by modifications to drbg.c? (Adding USE_64=1 to the make command won't help, because that makes the i386 part fail.) Kaspar If this is the only place where Universal fails, then we can set NS_PTR_GR_32 for the universal binary. I'm a little worried that we'll get something suboptimal for the 64 bit case. Does mozilla build univeral binaries and how do the get them. (I always thought the universal binaries were built by building each arch separately and then combining them at the end). bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On 20.1.11 20:57, Robert Relyea wrote: On 01/19/2011 10:36 PM, Kaspar Brand wrote: That's certainly doable, but I don't think the NSS build system has support for building universal binaries (you'd have to fiddle with lipo yourself). I think it depends on what the Mac compiler kicks out. On Windows or Linux, the non-64 bit builds automatically set the compiler to produce 32-bit binaries unless the USE_64 is set. By default, GCC on OS X does not create universal binaries. Starting with 10.6 (Snow Leopard), the default changed from 32 to 64 bit, though. My guess is that no one has set the compiler flags correct for building 32-bit binaries on Mac 64. That's a perfect guess, yes: If you have the proper changes to coreconf to produce 32 bits on a Mac 64 bit system, we would certainly be interested. I think something like the attached patches (not only for NSS, but also for NSPR) should do the trick. Adding -arch options shouldn't hurt for older OS X versions. Building universal binaries for NSS in a single step, on the other hand, is something which doesn't work properly yet. In theory, this could be achieved by setting CC=gcc -arch x86_64 -arch i386 with the make command (which instructs GCC to compile separate versions and assemble them with lipo afterwards), but this will currently fail at drbg.c: gcc -arch x86_64 -arch i386 -o Darwin10.6.0_OPT.OBJ/Darwin_SINGLE_SHLIB/drbg.o -c -O2 -fPIC -Di386 -Wall -fno-common -pipe -DDARWIN -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\dylib\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -DMP_API_COMPATIBLE -I../../../../dist/Darwin10.6.0_OPT.OBJ/include -I../../../../dist/public/nss -I../../../../dist/private/nss -Impi -Iecl drbg.c drbg.c: In function 'RNG_RandomUpdate': drbg.c:516: error: size of array 'arg' is negative Looking at the current logic in drgb.c #if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) !defined(NS_PTR_LE_32)) PR_STATIC_ASSERT(sizeof(size_t) 4); #else PR_STATIC_ASSERT(sizeof(size_t) = 4); #endif this is due to GCC trying to compile for x86_64, but without NSS_USE_64 being set. Maybe this could be addressed by modifications to drbg.c? (Adding USE_64=1 to the make command won't help, because that makes the i386 part fail.) Kaspar Index: coreconf/Darwin.mk === RCS file: /cvsroot/mozilla/security/coreconf/Darwin.mk,v retrieving revision 1.26 diff -u -r1.26 Darwin.mk --- coreconf/Darwin.mk 29 Jul 2010 00:49:06 - 1.26 +++ coreconf/Darwin.mk 22 Jan 2011 11:26:49 - @@ -54,9 +54,11 @@ CC += -arch x86_64 else OS_REL_CFLAGS = -Di386 +CC += -arch i386 endif else OS_REL_CFLAGS = -Dppc +CC += -arch ppc endif ifneq (,$(MACOS_SDK_DIR)) Index: configure.in === RCS file: /cvsroot/mozilla/nsprpub/configure.in,v retrieving revision 1.295 diff -u -r1.295 configure.in --- configure.in21 Jan 2011 23:43:59 - 1.295 +++ configure.in22 Jan 2011 11:25:27 - @@ -1144,10 +1144,12 @@ CC=$CC -arch x86_64 else CPU_ARCH=i386 +CC=$CC -arch i386 fi ;; *) CPU_ARCH=ppc +CC=$CC -arch ppc ;; esac DSO_CFLAGS=-fPIC -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On Wed, Jan 19, 2011 at 8:08 PM, Nathan Craike ncra...@gmail.com wrote: Is it possible to build the 32-bit version on a 64-bit Mac? The Mac OS X man page for gcc describes an Apple only option -arch: -arch arch Compile for the specified target architecture arch. The allowable values are i386, x86_64, ppc and ppc64. ...but same error occurs (the failing assertion) if I run the make script with this option, as below: ncraike@ncraikework 15:54:40 ~/Installs/nss-3.12.9/mozilla/security/nss $ CC=gcc -arch i386 CXX=g++ -arch i386 make nss_build_all The correct command is to pass CC and CXX (or rather, CCC, which is the variable name used by NSS) to make as make variables as opposed to environment variables: $ make nss_build_all CC=gcc -arch i386 CCC=g++ -arch i386 If I set the USE_64 environment variable: ncraike@ncraikework 16:00:09 ~/Installs/nss-3.12.9/mozilla/security/nss $ USE_64=1 make nss_build_all Similarly, this should be $ make nss_build_all USE_64=1 although passing USE_64=1 as an environment variable also works. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Problems Building NSS on Mac OS X 10.6 (64-bit)
On 20.01.2011 05:08, Nathan Craike wrote: I'd eventually like to include the built libraries in software deployed an any machine running Mac OS X 10.6, which may be Intel 32-bit or 64-bit machines, so a build which works on both architectures would be preferred (either 32-bit or some kind of universal binary, I assume). That's certainly doable, but I don't think the NSS build system has support for building universal binaries (you'd have to fiddle with lipo yourself). Should I be able to build the 32-bit version of NSS? Should this assertion be failing? I also ran into this previously, and added -DNS_PTR_GT_32 to the OS_REL_CFLAGS = -Di386 line in Darwin.mk. Not sure if that's the proper way of fixing things, though. Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
