Bug 725340 - nss and nspr doesn't build on s390x when --target=s390 and --target=s390x are set
Summary: nss and nspr doesn't build on s390x when --target=s390 and --target=s390x are...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss
Version: 5.7
Hardware: s390x
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Elio Maldonado Batiz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-25 08:51 UTC by Aleš Mareček
Modified: 2013-06-14 10:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-20 22:39:17 UTC
Target Upstream Version:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.