Closed Bug 233048 Opened 21 years ago Closed 20 years ago

64bit build does not work on solaris with gcc

Categories

(NSS :: Build, defect, P2)

Sun
Solaris
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Vladimir.Marek, Assigned: wtc)

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       
Build Identifier: 

after running
CXX=g++ CC=gcc ./configure --enable-64bit

makefiles are not set in order to build 64bit version

Reproducible: Always
Steps to Reproduce:
1. Download and unpack nss-3.9.tar.gz
2. cd nss-3.9/mozilla/nsprpub
3. CXX=g++ CC=gcc ./configure --enable-64bit
4. make

Actual Results:  
[...]
gcc -o prfdcach.o -c     -Wall -pthreads -g -fPIC  -UNDEBUG -DDEBUG_prints 
-DDEBUG=1 -DXP_UNIX=1 -DSVR4=1 -DSYSV=1 -D__svr4=1 -D__svr4__=1 -DSOLARIS=1
-DHAVE_FCNTL_FILE_LOCKING=1 -D_PR_HAVE_OFF64_T=1 -D_LARGEFILE64_SOURCE=1
-DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -D_REENTRANT=1 -DHAVE_POINTER_LOCALTIME_R=1 
-DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_
-I../../../dist/include/nspr -I../../../pr/include -I../../../pr/include/private
 prfdcach.c
[...]

Expected Results:  
64bit build

We can somehow get near to expected result by:

LDFLAGS=-m64 CFLAGS='-m64 -mcpu=ultrasparc' CXX=g++ CC=gcc ./configure
--enable-64bit

object files are then build with 64bit support, but dynamic libraries are still
not linked 64bit wise
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: other → Solaris
Hardware: Other → Sun
Are you trying to build NSPR standalone, or are you trying to
build NSPR as a pre-requisite for NSS?

You need to modify the following code in mozilla/nsprpub/configure.in
so that we use the right compiler flags (-m64 -mcpu=ultrasparc ?)
for gcc if USE_64 is 1:

    if test -n "$USE_64" && test -z "$GNU_CC"; then
        CC="$CC -xarch=v9"
        CXX="$CXX -xarch=v9"
    fi
Status: NEW → ASSIGNED
Version: unspecified → 3.9
Vladimír:
Slighly offtopic: gcc's support for 64bit sparc is still very buggy. It may
compile but I doubt the resulting binaries will work properly (at least Solaris
64bit kernel modules and Xfree86 do not work properly when compiled with gcc in
64bit mode ... ;-( ), additionally shared libraries compiled with gcc cannot be
used from applications compiled with Sun Workshop (that's a gcc bug, shared
libraries compiled with Sun Workshop work with both gcc- and Sun
Workshop-compiled applications (we hit that issue that often with libGTK/libGDK
that it had to be listed in the release notes for Mozilla ;-( )).
As in my previous bug report, I was not following fully build instructions. As
punishment I'm attaching patch which will make building 64bit on solaris using
gcc a bit simplier. The right set of environment variables seems to be:

CC=gcc
CXX=g++
USE_64=1
NO_MDUPDATE=1
NS_USE_GCC=1
LDFLAGS=-m64
CFLAGS='-m64 -mcpu=ultrasparc'

(maybe it could be stated somewhere in documentation ?)

Sorry again for my ignorance with reading build instructions
The patch is tweaking configure instead of configure.in. This is wrong, but I'm
not able to do better, since I'm not able to create new configure from
configure.in.
Thanks for the patch.  Our goal is that one should
only need to set two environment variables:
USE_64=1
NS_USE_GCC=1

1. NO_MDUPDATE is obsolete.  You don't need it with
NSS 3.9.
2. If NS_USE_GCC is 1, NSS will pass CC=gcc CXX=g++
to nsprpub/configure, so it is not necessary to
set CC and CXX in the environment.
3. I believe that nsprpub/configure does not check
LDFLAGS, so it is not necessary to set LDFLAGS.
Your nsprpub/configure patch already adds -m4 to
the right variable (DSO_LDOPTS).
4. nsprpub/configure does check CFLAGS, but we want
to hardcode the value -m64 -mcpu=ultrasparc in
nsprpub/configure.  I believe you just need to modify
the code I pointed out in comment 1.

Let me know if you can make these changes.

Does your 64-bit gcc Solaris build work?
Comment on attachment 140737 [details] [diff] [review]
Easy build of nss 64bit on solaris with gcc

1. Do we really need -mcpu=ultrasparc for a 64-bit build?

2. Why do we need -DHAVE_SVID_GETTOD in
mozilla/security/coreconf/SunOS5.mk?
I remade the patch, so now only two environment variables are needed:

NS_USE_GCC=1
USE_64=1
plus optionally BUILD_OPT=1

To your questions:
1) NO_MDUPDATE not needed now
2) You're right, CC and GXX is set automatically
3,4) CFLAGS, LDFLAGS now not needed
5) I patched also testing suite, now test seems to work well in debug in release
build. How can I find out if they are right ? all.sh returns with return value
0, and I saw no apparent errors. I can send log from the tests, if it will be
usefull.

b1) -mcpu=ultrasparc trully is not needet too, it's just my habbit, I removed it
from patch
b2) -DHAVE_SVID_GETTOD was needed, otherwise gettimeofday was called with wrong
nuber of parameters. However, this patch fixed it somehow, so that it's not
needed anymore :)
This patch is NOT cumulative patch to previous one, it's replacement.
Attachment #140737 - Attachment is obsolete: true
Our test instructions at
http://www.mozilla.org/projects/security/pki/nss/testnss_32.html
explain where to find the test results and the
test output log file.

Thanks for the patch.  Would be interested to
know if the test results are all "Pass".
This is my version of Vladimír Marek's patch,
after some editing.

Vladimír, could you try this patch?  After applying
this patch, you need to regenerate NSPR's configure
script:
    cd mozilla/nsprpub
    autoconf

If you don't have autoconf, you need to manually
modify mozilla/nsprpub/configure the same way I
changed mozilla/nsprpub/configure.in.

Let me know if this patch works for you.  Thanks.
Comment on attachment 141178 [details] [diff] [review]
Proposed patch v1.1

Nelson, this patch supports building NSPR and
NSS for 64-bit Solaris SPARC using gcc.

You only need to review the NSS portion of
this patch.  The change to tests/common/init.sh
is similar to cmd/shlibsign/sign.sh, rev. 1.13.
Attachment #141178 - Flags: review?(MisterSSL)
Comment on attachment 141178 [details] [diff] [review]
Proposed patch v1.1

Wan-Teh, 
The patch to mozilla/security/coreconf/SunOS5.mk looks OK to me, but 
I would like to discuss the patch to mozilla/security/nss/tests/common/init.sh
with you.
The reason we need to preserve the old LD_LIBRARY_PATH
value is that starting in GCC 3.0, libgcc is a shared
library and gcc compiled programs must add the location
of libgcc.so to their LD_LIBRARY_PATH in order to run.

In order to run a gcc-compiled shlibsign or other
NSS command-line tools, LD_LIBRARY_PATH must contain
the location of libgcc.so, and therefore we must
prepend ${DIST}/${OBJDIR}/lib to the old value of
LD_LIBRARY_PATH, rather than setting LD_LIBRARY_PATH to
${DIST}/${OBJDIR}/lib.

Then, I extended the same change to the equivalent
environment variables for some Unix variants (SHLIB_PATH
for HP-UX, LIBPATH for AIX, and DYLD_LIBRARY_PATH for
Mac OS X).

Finally, it is harmless to have a trailing ':' in
LD_LIBRARY_PATH.
Comment on attachment 141178 [details] [diff] [review]
Proposed patch v1.1

Once I woke up enough to realize this was a shell script and not a makefile, my
only remaining concern was for the trailing ':'.
r=MisterSSL
Attachment #141178 - Flags: review?(MisterSSL) → review+
Patch v1.1 has been checked into the NSS tip (NSS 3.10)
and NSPR tip (NSPR 4.5).

It is not in the Mozilla trunk build yet.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.10
Setting priorities on unprioritized bugs resolved fixed for NSS 3.10.
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: