301326 - Standardize the position of "_64" in OBJDIR_NAME

Status: RESOLVED WONTFIX

(NSS :: Build, defect)

Description

[Wan-Teh Chang]

With the recent change to treat AMD64/EM64T as the
64-bit version (USE_64=1) of the "x86" CPU architecture
in NSPR and NSS, these two build systems produce
different OBJDIR_NAME for AMD64/EM64T.

Looking into this, I found that NSPR's build system has
a bug, and I believe that NSS's coreconf build system
also has a bug.

In any case, we need to standardize the OBJDIR_NAME
between NSPR and NSS for our AMD64/EM64T builds.

I propose that we put the "_64" tag immediately after
the CPU architecture tag (e.g., "x86").  The reasons
are:
- This is the original position.  The first evidence
  is the IRIX6.5_n32_PTH_DBG.OBJ directory name, where
  the similar "_n32" tag is before "_PTH".  The second
  evidence is the original NSPR build system (try
  cvs co -r NSPRPUB_RELEASE_3_5 mozilla/nsprpub/config),
  which uses COMPILER_TAG for "_64" and "_n32".
- For AMD64/EM64T this produces "x86_64", as if we didn't
  change the CPU_TAG in the first place.

Comment 1

[Wan-Teh Chang]

Attachment: NSPR patch, v1

You need to regenerate mozilla/nsprpub/configure after
applying this patch.

I use the new variable ABI_TAG for "_n32" or "_64".
IRIX documentation refers to N32 or 64-bit builds as
ABI's, hence the name.	I am not happy with this name.
Suggestions welcome.

This patch only addresses Linux/x86_64.  I suspect
that NSPR doesn't produce the right OBJDIR_NAME for
Solaris on x64.

Comment 2

[Julien Pierre]

Wan-Teh,

Both NSPR and NSS produce the following OBJDIRs for Solaris :
SunOS5.10_64_DBG.OBJ - sparcv9
SunOS5.10_64_OPT.OBJ - sparcv9
SunOS5.10_DBG.OBJ - sparcv8
SunOS5.10_OPT.OBJ - sparcv8
SunOS5.10_i86pc_64_DBG.OBJ - amd64
SunOS5.10_i86pc_64_OPT.OBJ - amd64
SunOS5.10_i86pc_DBG.OBJ - x86
SunOS5.10_i86pc_OPT.OBJ - x86

I don't see a big need to change those OBJDIRs, as everybody has been using them
for a while at Sun. I don't mind if the way those OBJDIRs are constructed change
if the values remain the same. If the OBJDIR names change, we'll have to use
symlinks in /share/builds/components .

Comment 3

[Wan-Teh Chang]

Attachment: NSS patch, v1

This patch considers x86_64/AMD64/EM64T a 64-bit version
(USE_64=1) of the x86 CPU architecture (CPU_ARCH=x86) on
both Linux and Solaris.

If you find this too confusing, I can use a different way
to accomplish the goal -- set CPU_TAG to "x86" (Linux only)
and leave CPU_ARCH as "x86_64".

Comment 4

[Wan-Teh Chang]

Attachment: NSS patch, v1 (whitespace changes ignored)

For easier code review.

Comment 5

[Wan-Teh Chang]

Julien:

I looked at mozilla/nsprpub/configure.in again and now believe
it produces the correct OBJDIR directory names for Solaris on
x64/x86, as you listed in comment 2.

Just to be sure, could you do a standalone NSPR build (not as part
of gmake nss_build_all), and look at the RELEASE_OBJDIR_NAME value
in the autoconf.mk file (generated from mozilla/nsprpub/config/autoconf.mk.in
by mozilla/nsprpub/configure)?  You only need to do the configure
step, it's not necessary to do "gmake".

Comment 6

[Julien Pierre]

Wan-Teh,

I tried to run configure on a virgin tree on a Solaris AMD64 box. I ran
configure with no options.
The RELEASE_OBJDIR_NAME was set to SunOS5.10_i86pc_DBG.OBJ .
I tried to set USE_64, BUILD_OPT, and NS_USE_GCC environment variables to 1, and
reran configure, but these had no effect on the RELEASE_OBJDIR_NAME, as they
should have. Do I need to pass any options to configure ?

Comment 7

[Christophe Ravel]

Is there any reason why we should change how USE_64 is tested ?

It used to be:
ifeq ($(USE_64),1)

In your patch, it is:
ifdef USE_64

We had a serious issue last year with ECC related to the way we test the flag.
If there is no compeling reason to change, I would prefer to keep it the way it was.

Comment 8

[Wan-Teh Chang]

Julien: in NSPR, most build options are configure options.
Specifically, here is how you do these things:

NSS (coreconf)   NSPR
------------------------------------------------------------
USE_64           configure --enable-64bit
BUILD_OPT        configure --disable-debug --enable-optimize
NS_USE_GCC       env CC=gcc configure
OS_TARGET=WIN95  configure --enable-win32-target=WIN95
USE_DEBUG_RTL    configure --enable-debug-rtl

Christophe: I considered that issue but found that there are
already ifdef/ifndef USE_64 checks in NSS.   See
http://lxr.mozilla.org/security/search?string=USE_64.

In general coreconf make variables need to be unset (FOO=),
rather than set to 0 (FOO=0), to turn off the build options.
It has always been this way.  See BUILD_OPT, the most
commonly used coreconf make variable, as an example:
http://lxr.mozilla.org/security/search?string=BUILD_OPT.

Comment 9

[Julien Pierre]

Thanks, Wan-Teh. I checked the OBJDIRs with the standalone configure, and they
were all as I posted in comment #2 .

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Regarding _n32, at one time, IRIX for mips supported 3 ABIs, two 32-bit ABIs
and one 64-bit ABI.  The newer 32-bit ABI was named n32.  It permitted using
64-bit registers in an otherwise 32-bit ABI.  I think n32 was considered a
32-bit ABI because pointers were 32-bit.  IIRC, at one time, we built NSS
for all 3 ABIs on IRIX.  I've heard that IRIX eventually supported a second
64-bit ABI too, but we never added that support to NSS.

My point is just that I think this part of the objdir name needs to not be
thought of as exclusively containing either "32" or "64", but rather as 
indicating an ABI.  Any platform that supports multiple ABIs of the same
fundamental (pointer) size should be able to do separate builds for each 
of those ABIs, if they so choose.  

Comment 11

[Franziskus Kiefer [:franziskus]]

This doesn't seem to go anywhere, it's been 10 years now.