290725 - --enable-64bit flag is silly

Status: REOPENED

(NSPR :: NSPR, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

There is no need for a configure flag for this.  Otherwise, 32 bit architectures
can pass it.  We should determine whether the arch supports 64 bit
programmatically.  For an example, see e.g.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/configure.in&rev=1.1440&mark=840-854#840

Comment 1

[Julien Pierre]

Christopher,

Many 64-bit platforms also support 32-bit applications.
Oftentimes, one wants to build 32-bit even if the OS underneath supports
64-bits. One should not assume that a 64-bit build is wanted just because the OS
supports it.

On most platforms, the default is to build 32 bits, regardless of the capability
of the OS. It looks like for Linux, the build system for NSPR and NSS is changed
to default to 64 if the OS supports it. I think that's inconsistent and wrong.

Comment 2

[Wan-Teh Chang]

The --enable-64bit configure option (and its equivalent USE_64
make variable in NSS's coreconf) is valuable for people who need
to build on multiple platforms.  It is hard to remember the right
compiler flags for doing a 64-bit build on every platform.  For
example, the flag is:
* -xarch=v9 for Solaris SPARC with Sun compiler
* -xarch=amd64 for Solaris x86-64 with Sun compilers
* +DA2.0W for +DD64 for HP-UX with HP compilers

On those platforms, if you don't specify the right flag, the
compiler produces 32-bit binaries, which will work just fine
on those platforms.

So, the --enable-64bit configure option and its NSS coreconf
equivalent are important to the NSPR and NSS developers.

Comment 3

[Wan-Teh Chang]

On 64-bit Linux platforms, the compiler generates 64-bit
binaries by default.  It may be possible to pass a flag
to generate 32-bit binaries, but I never received any
request to do that.  So right now you can only do 64-bit
NSPR and NSS builds on 64-bit Linux.  This limitation is
not necessarily a bad thing.

Comment 4

[Julien Pierre]

Wan-Teh,

In response to comment #3, I have had the need to generate 32-bit NSPR and NSS
Linux binaries while on a 64-bit Linux machine, and was unable to. I was forced
to use a 32-bit Linux machine for the build. Fortunately, such a machine was
available in our lab, but it wouldn't necessarily be available in a home
environment. I think this is a completely unecessary limitation of the build system.

Comment 5

[Wan-Teh Chang]

Julien, if you figure out how to tell gcc to do
a 32-bit x86 build on a Linux x86-64 system, please
let me know.

Comment 6

[Julien Pierre]

Wan-Teh,

gcc -m32 does this just fine.

Comment 7

[Christopher Aillon (sabbatical, not receiving bugmail)]

Autoconf is designed to figure this stuff out for you.  By using an
autoconf-based system, the application is expected to just do the right thing
and have the user pass in different CFLAGS if they want to change the build.  It
is not up to NSPR to determine what the default builds should be and change it
only if the --enable-64bit flag is turned on.

To be honest, this seems like it really only helps the NSPR developers.  People
who maintain systems know what compiler flags they need to use to get certain
things to happen.  That is not an unreasonable expectation to impose upon them,
as there are many other software applications that use autoconf and they do not
do require them to pass a similar flag.  It is an old artifact of older build
systems, and one that several people have asked me to file this bug on.

Re-open for reconsideration.

wtc: as a side note, Red Hat supports both 32 and 64 bit on 64 bit platforms, so
we need to make sure that we can build 32 bit on 64 bit platforms.  We do it all
the time -- that's the beauty of autoconf.  Configure your build system in one
central location and it just works without needing to pass --enable-32|64bit
flags.  Just pass -m32 in your CFLAGS.

Comment 8

[Julien Pierre]

Chris,

Autoconf cannot possibly peak into my brain and figure out if I want to build 32
bit and 64 bits today. That's strictly my decision as a developer. Sometimes I
want to build one, sometimes the other. The NSPR/NSS build systems need to allow
building either one.

On every platform but Linux 64 bit, we specify the bitness of the NSS target
with the environment variable USE_64 . I guess this in turns sets the
--enable-64bit option when building NSPR  On Linux though, the USE_64 variable
is ignored, and the build always ends up as 64 bits if the host is 64 bits.

I think the default for Linux should be changed to 32 bits, to be consistent
with all other platforms. I would rather we don't add a USE_32 variable or
--enable-32bit .

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Chris, we have need to build separate 32-bit and 64-bit builds of NSPR and NSS 
on numerous platforms that support both modes of operation, including 
Solaris, HPUX and AIX, to name a few.   Although we nearly always use 64-bit
machines for builds, we cross-build for 32-bit CPUs also on those platforms.
Quite a few products that use NSS and that run on 64-bit capable CPUs still
produce only 32-bit builds of their products.  Some produce both flavors.
So, we need the capability to explicitly control the register model (ILP32, 
or LP64) in those library products.  

I think your request could be interpreted as suggesting that, by default,
NSPR (and NSS?) build with the native register width of the system on 
which they are running.  Is that a fair assessment?  

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

Basically the idea is this:

With --enable-64bit, you can create both 32bit and 64bit builds on 64bit machines.
With autoconf and CFLAGS doing it automatically, you can ALSO create both 32bit
and 64bit builds on 64bit machines.
*Every other autoconf based system* chooses one for you and requires the
developer to change their CFLAGS to override accordingly.

Why is NSPR different?  The only reason I've heard is that it is hard to
remember the correct CFLAGS.

That is a bogus answer.  If compiling any other app requires the user to know
the CFLAGS, then why can't NSPR?  It seems like it helps you guys since it is
hard to remember every option for every platform, and this is why you are
attached to it.  I understand that, but it is possible to write the right
options down and store them somewhere e.g. on your build webpages.  The
maintainers and admins of machines do know their CFLAGS because they have to. 
You aren't "helping" them really, just making NSPR different from the rest of
the autoconf world.

I see both "classic" and "autoconf" versions of build instructions.  Autoconf
should not need --enable-64bit.  If you want to keep --enable-64bit for the
classic build, by all means do so.

Comment 11

[Julien Pierre]

Chris,

I think you just made our case - we as developers don't want to remember the
specific CFLAGS for every platform in order to be able to change the bitness.
Sometimes we even compile with different compilers on the same platform (look at
Solaris for example, which can build with either Sun studio or gcc). In those
cases we use another environment/make variable called NS_USE_GCC, just as we
have USE_64 . The --enable-64bit option enables the 32 vs 64 bit choice as a
simple platform-independent toggle, and provides a very valuable service to us,
the NSPR and NSS developers, without having to look at a build web page. The set
of compiler flags we use to build NSPR, including those to select the bitness,
is IMO information that belongs in the files that are checked in to CVS, not
outside of it.

Comment 12

[Wan-Teh Chang]

--enable-64bit is valuable to anyone who needs to
work on multiple platforms or a new platform.

Although we rewrote NSPR's build system using
autoconf, we don't want to lose the nice qualities
of our original build system.  So I will not
remove the --enable-64bit configure option.

But we may be able to allow both styles.  Before I
propose a solution, I need to know what problem
to solve.  Could you tell me concretely how you
would like to configure NSPR for 64-bit builds
on as many platforms as you can?  I need the
complete configure command lines, including
any environment variables.  Thanks.

Comment 13

[Julien Pierre]

Chris,

Re: #10,

Here is a real problem I have to solve today. I am trying to build a 32-bit
version of NSPR on a 64-bit RedHat Linux 3 box. I know the compiler I have (gcc
3.4.3) will generate both 32-bit and 64-bit executables, with the appropriate
flags (-m32 or -m64). But I simply cannot get autoconf to select the right
target, CFLAGS or not. Please tell exactly how you succeeded doing this and how
easy it was for you to do it.

Keep in mind that the NSPR build requires more than just knowledge of the CFLAGS !
NSPR will compile and assemble different assembly files (.s files) for 32-bit
and 64-bit builds.  I invite you to look at
mozilla/nsprpub/pr/src/md/unix/Makefile.in .
The developer should not be expected to have to make manual changes to do it.

IMO, when the local machine has more than one possible target, then the entire
concept of autoconf is fundamentally broken . autoconf cannot figure out what
the correct target is without a hint from the user . It is the same as with
cross-compilers.

It is a fundamental need of the developers at Sun to be able to easily choose
the target when the local machine has multiple targets. We don't need to
cross-compile between different CPU architectures . But even just to choose
bitness (32 or 64) for the local machine, setting CFLAGS doesn't do the job, and
it is hard.

--enable-64-bit is not silly - it is important we keep it. And we should also
add --enable-32-bit for the platform that defaults to 64 bits to change the
target to 32 bits easily.

Comment 14

[Julien Pierre]

Chris, FYI, this is the result of your suggestion of setting CFLAGS to -m32 with
autoconf .

[nss-amd-linux]/h/monstre/export/home/perf/mozilla/security/nss 209 % gmake
build_nspr CFLAGS=-m32
../coreconf/nsinstall/Linux2.4_x86_64_glibc_PTH_OPT.OBJ/nsinstall -D
../../nsprpub/Linux2.4_x86_64_glibc_PTH_OPT.OBJ
cd ../../nsprpub/Linux2.4_x86_64_glibc_PTH_OPT.OBJ ; \
 sh ../configure \
--disable-debug --enable-optimize \
--with-dist-prefix='/.automount/monstre/root/export/home/perf/mozilla/security/nss/../../dist/Linux2.4_x86_64_glibc_PTH_OPT.OBJ'
\
--with-dist-includedir='/.automount/monstre/root/export/home/perf/mozilla/security/nss/../../dist/Linux2.4_x86_64_glibc_PTH_OPT.OBJ/include'
creating cache ./config.cache
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking for whoami... /usr/bin/whoami
checking for c++... c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... yes
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for gcc... gcc
checking whether the C compiler (gcc -m32 ) works... yes
checking whether the C compiler (gcc -m32 ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking for as... /usr/bin/as
checking for ar... /usr/bin/ar
checking for ld... /usr/bin/ld
checking for strip... /usr/bin/strip
checking for windres... no
checking for gcc -pipe support... yes
checking for visibility(hidden) attribute... yes
checking for visibility pragma support... no
checking for perl5... no
checking for perl... /usr/bin/perl
checking for dlopen in -ldl... yes
checking for dlfcn.h... yes
checking whether gcc needs -traditional... no
checking for lchown... yes
checking for strerror... yes
checking for pthread_create in -lpthreads... no
checking for pthread_create in -lpthread... yes
checking whether gcc accepts -pthread... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating config/Makefile
creating config/autoconf.mk
creating config/nsprincl.mk
creating config/nsprincl.sh
creating config/nspr-config
creating lib/Makefile
creating lib/ds/Makefile
creating lib/libc/Makefile
creating lib/libc/include/Makefile
creating lib/libc/src/Makefile
creating lib/tests/Makefile
creating pkg/Makefile
creating pkg/linux/Makefile
creating pkg/solaris/Makefile
creating pkg/solaris/SUNWpr/Makefile
creating pkg/solaris/SUNWprd/Makefile
creating pr/Makefile
creating pr/include/Makefile
creating pr/include/md/Makefile
creating pr/include/obsolete/Makefile
creating pr/include/private/Makefile
creating pr/src/Makefile
creating pr/src/io/Makefile
creating pr/src/linking/Makefile
creating pr/src/malloc/Makefile
creating pr/src/md/Makefile
creating pr/src/md/unix/Makefile
creating pr/src/memory/Makefile
creating pr/src/misc/Makefile
creating pr/src/threads/Makefile
creating pr/tests/Makefile
creating pr/tests/dll/Makefile
creating pr/src/pthreads/Makefile
cd ../../nsprpub/Linux2.4_x86_64_glibc_PTH_OPT.OBJ ; gmake
gmake[1]: Entering directory
`/.automount/monstre/root/export/home/perf/mozilla/nsprpub/Linux2.4_x86_64_glibc_PTH_OPT.OBJ'
cd config; gmake -j1 export
gmake[2]: Entering directory
`/.automount/monstre/root/export/home/perf/mozilla/nsprpub/Linux2.4_x86_64_glibc_PTH_OPT.OBJ/config'
gcc -o now.o -c -m32 ../../config/now.c
../../config/now.c:50:2: #error "Architecture not supported"
../../config/now.c:136:2: #error "Architecture not supported"

Comment 15

[Wolfgang Rosenauer [:wolfiR]]

sorry, I don't know about RedHat but SUSE has a tool called "linux32" which
changes the personality for exec'ed processes. By using this, autoconf should
think it's a i686 system.

Comment 16

[cls]

Attachment: Do not default to 64bit builds on x86_64 or ia64 linux

This patch takes into account the USE_64 flag when setting PR_MD_ASFILES for
linux.	Standalone NSPR x86_64/ia64 builds will need to pass --enable-64bit to
get a 64bit build.  The Mozilla builds will automatically pass --enable-64bit
to NSPR (& LDAP) based upon whether or not |sizeof(long long) == 8| is true
(yeah, yeah see bug 215688) which can be controlled by passing "CC='gcc -m32'
CXX='g++ -m32' CPP='cpp -m32'" to configure.

Comment 17

[Julien Pierre]

Thanks, Chris ! I need a similar fix for the NSS coreconf in order to test this
configure change, as I always build NSPR with "gmake build_coreconf build_nspr"
from mozilla/security/nss . I'll see if I can come up with that coreconf change
to test the NSPR configure change.

Comment 18

[cls]

There seem to be some serious misconceptions about the limitations of autoconf
so let me attempt to clear them up.

(In reply to comment #8)
> Autoconf cannot possibly peak into my brain and figure out if I want to build 32
> bit and 64 bits today. That's strictly my decision as a developer. Sometimes I
> want to build one, sometimes the other. The NSPR/NSS build systems need to allow
> building either one.

As caillon pointed out, you can pass flags to configure to tell it exactly what
you want to use.  Whether it's CFLAGS or a configure option makes no difference,
IMO.  That's the same as setting a bunch of environment variables with coreconf.

> On every platform but Linux 64 bit, we specify the bitness of the NSS target
> with the environment variable USE_64 . I guess this in turns sets the
> --enable-64bit option when building NSPR  On Linux though, the USE_64 variable
> is ignored, and the build always ends up as 64 bits if the host is 64 bits.

That's an implementation bug that the patch I attached should fix.

(In reply to comment #13)

> Keep in mind that the NSPR build requires more than just knowledge of the CFLAGS !
> NSPR will compile and assemble different assembly files (.s files) for 32-bit
> and 64-bit builds.  I invite you to look at
> mozilla/nsprpub/pr/src/md/unix/Makefile.in .
> The developer should not be expected to have to make manual changes to do it.

No, they shouldn't.  The build system should and does take care of that.

> IMO, when the local machine has more than one possible target, then the entire
> concept of autoconf is fundamentally broken . autoconf cannot figure out what
> the correct target is without a hint from the user . It is the same as with
> cross-compilers.

How is this any different than coreconf?  Either you like the default setup or
you have to pass in a bunch of flags to get the build to work as you'd like. 
See mozilla/security/manager/Makefile.in for evidence of that.  Unlike coreconf,
there are a number of ways to work around the issue with a properly setup
autoconf system:  set CC/CFLAGS, use specific --enable-options or use the
--target=x86_64-linux option.  

> It is a fundamental need of the developers at Sun to be able to easily choose
> the target when the local machine has multiple targets. We don't need to
> cross-compile between different CPU architectures . But even just to choose
> bitness (32 or 64) for the local machine, setting CFLAGS doesn't do the job, and
> it is hard.

It sounds like you really want to use --target then.  While $build != $target
implies cross-compiling, the system doesn't have to special case the build if
the targets are obviously compatible.

Setting CFLAGS doesn't do the job with NSPR because the system, being ported
from coreconf, wasn't designed that way.  Setting CFLAGS works with building
gecko because we did take that case into account.  

> --enable-64-bit is not silly - it is important we keep it. And we should also
> add --enable-32-bit for the platform that defaults to 64 bits to change the
> target to 32 bits easily.

Adding --enable-32-bit will only further confuse the issue.  What happens when
both are specified?  Since one essentially overrides the other, why have both? 
Since every --enable- option implicitly has a --disable- counterpart, we could
easily modify --disable-64bit to do the same thing as adding an --enable-32bit
option.  

Comment 19

[Wolfgang Rosenauer [:wolfiR]]

For the record: I don't like this approach!
autoconf based systems should build for the architecture/platform where there
are build without any options.
One more thing is that IA64 is not designed to be biarch (while it's possible
currently with the emulation layer). So if you compile an application on Linux
IA64 you definitely want a 64bit build.
And for the case the patch gets in ignoring the above, don't forget s390x

Comment 20

[Julien Pierre]

Chris,

I made the required changes to the NSS coreconf which cause it not to pass
--enable-64bit by default, unless USE_64 is set . For the record, this is how
the NSS Makefile invokes the NSPR configure when I do this.

 sh ../configure \
 \
--with-dist-prefix='/.automount/monstre/root/export/home/newtip/mozilla/security/nss/../../dist/Linux2.4_x86_glibc_PT
H_DBG.OBJ' \
--with-dist-includedir='/.automount/monstre/root/export/home/newtip/mozilla/security/nss/../../dist/Linux2.4_x86_glib
c_PTH_DBG.OBJ/include'

The expectation for this case is that configure should produce a 64-bit build,
since --enable-64-bit has not been passed in .

Your NSPR patch was not sufficient to make the build work, because the
compiler/linker defaults to -m64. So, the 32-bit assembly file was assembled
with -m64, and that failed . configure needs to be fixed to pass -m32 to gcc
when USE_64 is not set . This is only strictly necessary when running on the
x86-64 bi-arch platform . 

I was able to build NSPR 32-bit by adding the following to your patch in the x86
case statement, right after PR_MD_ASFILES=os_Linux_x86.s :

+			CFLAGS="$CFLAGS -m32"
+			LDFLAGS="$LDFLAGS -m32"
+			DSO_LDOPTS="$DSO_LDOPTS -m32"

Re : comment #18 :

Chris,

The mozilla/security/nss/Makefile, in the build_nspr target, never passes any
CFLAGS to the NSPR configure on any platform . For the bi-arch platforms 32/64
bits, the default is 32 bits, and 64 bits is enabled with the USE_64 variable,
which causes configure to pass --enable-64bit to NSPR configure . This is much
simpler than forcing NSS to pass specific flags to configure for each bi-arch
platform. --enable-64bit is a simple enough, unified protocol to follow.

FYI, we don't support cross-compiling with NSS at all, in the true meaning of
the word - producing binaries that don't run on the build machine at all. The
reason is that the NSS tool shlibsign needs to be run as part of the build. If
we wanted to ever support cross-compiling, we would need to do two builds, first
a build for the local architecture, and then the build for the target
architecture, which would invoke the shlibsign from the local build ... But we
have no interest in doing true cross-compiling at this time.

Re: enable-32 . Yes, it would be more confusing. I was only suggesting it would
be needed because the precedent for Linux Mozilla builds has been to build
64-bit by default, if allowed by the local host; which is different than the
coreconf default, which is to always build 32-bit by default on bi-arch
platforms, unless USE_64 is set . I'm fine with the approach you took in your
patch, which makes 32-bits the default .

Re : comment #19 :

I agree we should only change this for x86-64 or other biarch platforms on which
USE_64 needs to be processed.

Comment 21

[Julien Pierre]

Attachment: support 32-bit x86 builds on x86-64 host , and USE_64 environment variable

Comment 22

[Wan-Teh Chang]

Comment on attachment 186651 [details] [diff] [review]
support 32-bit x86 builds on x86-64 host , and USE_64 environment variable

>+			CFLAGS="$CFLAGS -m32"
>+			LDFLAGS="$LDFLAGS -m32"
>+			DSO_LDOPTS="$DSO_LDOPTS -m32"

In NSPR, you can replace the above three by
    CC="$CC -m32"
    CXX="$CXX -m32"

See how -m64 and -xarch=v9/amd64 are handled for Solaris.

Note: coreconf can't do this because Mozilla's build system
overrides coreconf's CC and CCC make variables in
mozilla/security/manager/Makefile.in.

Unless one of us tests this patch on a Linux/ia64 system,
this patch shouldn't include ia64 changes.

Please submit a new patch for configure.in instead.
configure is a generated file.

Comment 23

[Wan-Teh Chang]

Correction: Mozilla's build system doesn't override coreconf's
CCC variable because NSS doesn't have C++ code.

Comment 24

[Julien Pierre]

Wan-Teh,

coreconf has a CCC variable, and I have used it to build some C++ test programs
I wrote under nss/cmd successfully, even though none of them are checked in. The
coreconf CCC variable indeed doesn't get propagated to NSPR autoconf.

Comment 25

[Wan-Teh Chang]

Julien, you misunderstood my comment.  I said Mozilla overrides
coreconf's CC variable.  I didn't say coreconf overrides NSPR's
CC or CXX variable.

Since Mozilla overrides coreconf's CC variable, coreconf's CC
variable can't contain any important compiler flag such as -m32.
So important compiler flags have to be stored in other variables.

The reason Mozilla overrides coreconf's CC variable is that
Mozilla may use a GCC whose name is not simply "gcc" but
rather "/usr/local/bin/gcc" or "gcc4".  Since coreconf hardcodes
GCC's name as "gcc", Mozilla needs to overrides it.

Comment 26

[Julien Pierre]

Attachment: updated patch

Don't make any change for ia64.
Change CC and CCC rather than CFLAGS / LDFLAGS / DSO_LDOPTS

Comment 27

[Julien Pierre]

FYI, I only tested the configure change. I don't have the right version of
autoconf to check for proper generation of configure .

Comment 28

[Wan-Teh Chang]

Comment on attachment 188249 [details] [diff] [review]
updated patch

>Index: configure
>===================================================================
>RCS file: /cvsroot/mozilla/nsprpub/configure,v
>retrieving revision 1.187
>diff -u -1 -0 -r1.187 configure
>--- configure	2 Jun 2005 04:21:17 -0000	1.187
>+++ configure	4 Jul 2005 22:44:50 -0000
>@@ -3932,33 +3932,35 @@
> #define _ALPHA_ 1
> EOF
> 
>         cat >> confdefs.h <<\EOF
> #define __alpha 1
> EOF
> 
>         CFLAGS="$CFLAGS -mieee"
>         CXXFLAGS="$CXXFLAGS -mieee"
>         ;;
>-    i*86)
>+    i*86|x86_64)
>+        if test -n "$USE_64" -a "${target_cpu}" = "x86_64"; then
>+            PR_MD_ASFILES=os_Linux_x86_64.s
>+        else
>         cat >> confdefs.h <<\EOF
> #define i386 1
> EOF
>-
>-        PR_MD_ASFILES=os_Linux_x86.s
>+            PR_MD_ASFILES=os_Linux_x86.s
>+            CC="$CC -m32"
>+            CXX="$CXX -m32"    
>+        fi
>         ;;
>     ia64)
>         PR_MD_ASFILES=os_Linux_ia64.s
>         ;;
>-    x86_64)
>-        PR_MD_ASFILES=os_Linux_x86_64.s
>-        ;;
>     m68k)
>         CFLAGS="$CFLAGS -m68020-60"
>         CXXFLAGS="$CXXFLAGS -m68020-60"
>         ;;
>     esac    
>     ;;
> 
> *-mingw*|*-cygwin*|*-msvc*|*-mks*)
>     cat >> confdefs.h <<\EOF
> #define XP_PC 1
>Index: configure.in
>===================================================================
>RCS file: /cvsroot/mozilla/nsprpub/configure.in,v
>retrieving revision 1.189
>diff -u -1 -0 -r1.189 configure.in
>--- configure.in	2 Jun 2005 04:21:17 -0000	1.189
>+++ configure.in	4 Jul 2005 22:44:50 -0000
>@@ -1319,30 +1319,33 @@
>         CPU_ARCH=$OS_TEST
>     fi
>     CPU_ARCH_TAG=_${CPU_ARCH}
>     case "${target_cpu}" in
>     alpha)
>         AC_DEFINE(_ALPHA_)
>         AC_DEFINE(__alpha)
>         CFLAGS="$CFLAGS -mieee"
>         CXXFLAGS="$CXXFLAGS -mieee"
>         ;;
>-    i*86)
>-        AC_DEFINE(i386)
>-        PR_MD_ASFILES=os_Linux_x86.s
>+    i*86|x86_64)
>+        if test -n "$USE_64" -a "${target_cpu}" = "x86_64"; then
>+            PR_MD_ASFILES=os_Linux_x86_64.s
>+        else
>+            AC_DEFINE(i386)
>+            PR_MD_ASFILES=os_Linux_x86.s
>+            CC="$CC -m32"
>+            CXX="$CXX -m32"    
>+        fi
>         ;;
>     ia64)
>         PR_MD_ASFILES=os_Linux_ia64.s
>         ;;
>-    x86_64)
>-        PR_MD_ASFILES=os_Linux_x86_64.s
>-        ;;
>     m68k)
>         CFLAGS="$CFLAGS -m68020-60"
>         CXXFLAGS="$CXXFLAGS -m68020-60"
>         ;;
>     esac    
>     ;;
> 
> *-mingw*|*-cygwin*|*-msvc*|*-mks*)
>     AC_DEFINE(XP_PC)
>     AC_DEFINE(WIN32)

Comment 29

[Wan-Teh Chang]

Attachment: Implement USE_64 for x86_64 (checked in)

Note that the existing code for generating RELEASE_OBJDIR_NAME
(which is only used by the old Netscape binary distribution
repositories) happens to be correct for x86_64.  It'll set
CPU_ARCH_TAG to _x86 regardless of the setting of USE_64, and fix
it up with COMPILER_TAG ("_86" + "_64" = "_x86_64").

    if echo "$OS_TEST" | grep -c 86 >/dev/null; then
	CPU_ARCH=x86
    else
	CPU_ARCH=$OS_TEST
    fi
    CPU_ARCH_TAG=_${CPU_ARCH}
...
if test -n "$USE_64"; then
    COMPILER_TAG=_64
fi

RELEASE_OBJDIR_NAME="${OS_CONFIG}${CPU_ARCH_TAG}${COMPILER_TAG}${IMPL_STRATEGY}$

{OBJDIR_TAG}.${OBJDIR_SUFFIX}"

Comment 30

[Wan-Teh Chang]

Attachment: Use ABI_TAG for _64 and _n32

It turns out that what I said in comment 29 about the _64 tag
was wrong.  For Linux, we set COMPILER_TAG to _glibc, so it is
overwritten by _64 if USE_64 is set.  So we need to use different
variables for _glibc and _64.

This patch introduces a new variable ABI_TAG for _64 and _n32
(only used on SGI IRIX).  ABI_TAG may not be the best name for this
tag, but IRIX calls n32 and 64 "ABIs", hence the name.	We could
also call it BIT_TAG.

Comment 31

[Christophe Ravel]

The target milestone is already released. Resetting target milestone.

Comment 32

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 188346 [details] [diff] [review]
Implement USE_64 for x86_64 (checked in)

What is the status of this bug?  Is it still an issue?

Comment 33

[desrt]

GNOME carries a patch for this exact issue in jhbuild:

http://git.gnome.org/browse/jhbuild/tree/patches/nspr.config_64bits.patch

Comment 34

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.