Bug 725340

Summary:	nss and nspr doesn't build on s390x when --target=s390 and --target=s390x are set
Product:	Red Hat Enterprise Linux 5	Reporter:	Aleš Mareček <amarecek>
Component:	nss	Assignee:	Elio Maldonado Batiz <emaldona>
Status:	CLOSED WORKSFORME	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	5.7	CC:	hkario, kengert
Target Milestone:	rc
Target Release:	---
Hardware:	s390x
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-20 22:39:17 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Aleš Mareček 2011-07-25 08:51:10 UTC

Description of problem:
I tried to build nss and nspr source packages on s390x with both "target" flags set: s390 and s390x, build failed.

Version-Release number of selected component (if applicable):
nspr-4.8.6-1.el5.src.rpm
nss-3.12.8-4.el5_6.src.rpm

nspr-4.8.8-1.el5_7.src.rpm
nss-3.12.10-1.el5_7.src.rpm


How reproducible:
Always

Steps to Reproduce:
1. rpm -ivh nss-<current version>-src.rpm nspr-<current version>.src.rpm
2. NSS: rpmbuild --target=s390 --target=s390x /usr/src/redhat/SEPCS/nss.spec
3. NSPR: rpmbuild --target=s390 --target=s390x /usr/src/redhat/SEPCS/nspr.spec
  
Actual results:
nss:
$ rpmbuild --target=s390 --target=s390x -ba /usr/src/redhat/SPECS/nss.spec
- SNIP -
/usr/bin/ld: warning: s390:31-bit architecture of input file `../libpkix/pkix_pl_nss/module/Linux2.6_s390x_glibc_PTH_OPT.OBJ/pkix_pl_socket.o' is incompatible with s390:64-bit output
../certdb/Linux2.6_s390x_glibc_PTH_OPT.OBJ/alg1485.o: In function `CERT_GetOidString':
/usr/src/redhat/BUILD/nss-3.12.8/mozilla/security/nss/lib/certdb/alg1485.c:733: undefined reference to `__udivdi3'
collect2: ld returned 1 exit status
make[2]: *** [Linux2.6_s390x_glibc_PTH_OPT.OBJ/libnss3.so] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/nss-3.12.8/mozilla/security/nss/lib/nss'
make[1]: *** [libs] Error 2
make[1]: Leaving directory `/usr/src/redhat/BUILD/nss-3.12.8/mozilla/security/nss/lib'
make: *** [libs] Error 2
make: Leaving directory `/usr/src/redhat/BUILD/nss-3.12.8/mozilla/security/nss'
error: Bad exit status from /var/tmp/rpm-tmp.50743 (%build)


nspr (segfault?!):
$ rpmbuild --target=s390 --target=s390x -ba /usr/src/redhat/SPECS/nss.spec
- SNIP -
mozilla/nsprpub/pr/include/md/_unixware7.cfg ../../.././mozilla/nsprpub/pr/include/md/_win95.cfg ../../.././mozilla/nsprpub/pr/include/md/_winnt.cfg ../../../dist/include/nspr/md
make[3]: *** [export] Segmentation fault
make[3]: Leaving directory `/usr/src/redhat/BUILD/nspr-4.8.6/pr/include/md'
make[2]: *** [export] Error 2
make[2]: Leaving directory `/usr/src/redhat/BUILD/nspr-4.8.6/pr/include'
make[1]: *** [export] Error 2
make[1]: Leaving directory `/usr/src/redhat/BUILD/nspr-4.8.6/pr'
make: *** [export] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.58318 (%build)



Expected results:
Both packages are built (.s390, .s390x)

Additional info:
Build crashes because of --target=s390

Comment 1 RHEL Program Management 2011-09-23 00:54:47 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 2 Kai Engert (:kaie) (inactive account) 2013-02-19 16:29:34 UTC

Is this still a issue?

Given that apparently we have correct builds for both s390 and s390x in brew for NSS on RHEL 5.x, why is this a problem?

Comment 3 Elio Maldonado Batiz 2013-02-20 22:39:17 UTC

This should not an issue as we have since then had nspr/nss builds for s390/s390x on rhel-5.{7/8/9/10}. I'm closing this bug. Ales can always reopen it if it were to fail again.

Comment 4 Hubert Kario 2013-06-14 10:59:55 UTC

Also see bug 612454