Closed Bug 233048 Opened 21 years ago Closed 21 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: 21 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: