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
