551188 - support building nss on hpux with gcc and GNU-as

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[Michael Haubenwallner]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6) Gecko/20100111 Gentoo Firefox/3.5.6
Build Identifier: nss-3.12.5 on hppa2.0w-hp-hpux11.31

Compiling nss-3.12.5 on hpux using gcc (4.2.4) with GNU-as (binutils-2.19) does not work due to missing makefile support and GNU-as not understanding pseudo-ops used.

Reproducible: Always

Steps to Reproduce:
1. Build some gcc using the GNU-as too (as recommended by gcc),
or install precompiled hp-gcc package.
2. compile nss with 'gmake CC=gcc NS_USE_GCC=1'
Actual Results:  
gmake[1]: Entering directory `/tmp/nss-3.12.5/mozilla/security/coreconf/nsinstall'
gcc -o HP-UXB.11.31_gcc_DBG.OBJ/nsinstall.o -c -g -DHPUX10 -Ae +Z -DHPUX -Dhppa -D_HPUX_SOURCE -D_USE_BIG_FDS  -DHPUX11 -D_POSIX_C_SOURCE=199506L -DXP_UNIX -DDEBUG -UNDEBUG -DDEBUG_wie -DUSE_UTIL_DIRECTLY -I/tmp/nspr-4.8.3/install/include/nspr -I../../../dist/HP-UXB.11.31_gcc_DBG.OBJ/include -I../../../dist/public/coreconf -I../../../dist/private/coreconf  nsinstall.c
gcc: +Z: No such file or directory
<command-line>: error: missing '(' after predicate
gmake[1]: *** [HP-UXB.11.31_gcc_DBG.OBJ/nsinstall.o] Error 1
gmake[1]: Leaving directory `/tmp/nss-3.12.5/mozilla/security/coreconf/nsinstall'
gmake: *** [libs] Error 2


Expected Results:  
successful build

There is no support in NSS for gcc (using GNU-as) on hpux at all.

Comment 1

[Michael Haubenwallner]

Attachment: makefile-support for gcc on hpux

Comment 2

[Michael Haubenwallner]

Attachment: support GNU-as in ret_cr16.s (from bug#550428)

Comment 3

[Michael Haubenwallner]

Attachment: support GNU-as in hppa-hpux assembler files

third and last one.

Comment 4

[Michael Haubenwallner]

Attachment: support GNU-as in ret_cr16.s (from bug#550428)

Now only for ret_cr16.s without extra stuff.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Attachment: combined patch

I combined Michael Haubenwallner's above 3 patches into a single patch
that can be applied with patch -p0.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: combined patch as a cvs diff

This is Michael Haubenwallner's above 3 patches in cvs diff form,
which bugzilla's patch viewing tool prefers.  I will review this copy.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 432347 [details] [diff] [review]
combined patch as a cvs diff

There's one part of this patch that I question.  
It is this one-line change:

-        .LEVEL   2.0N
+        .LEVEL   2.0

please explain why you're making this change. 
If it's because gcc doesn't grok 2.0N, then 
I think you should ifdef this.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 432346 [details] [diff] [review]
combined patch

Michael, please submit any future versions of this patch in this form.
It is preferred to have one combined patch to numerous smaller ones.
I made this patch from yours by catting your patch files together,
then editing any lines with path names of files, removing the part
of the path name on the left up through mozilla/ .  
The results look like this:

>diff -ru security/coreconf/HP-UX.mk security/coreconf/HP-UX.mk
>--- security/coreconf/HP-UX.mk
>+++ security/coreconf/HP-UX.mk

Comment 9

[Michael Haubenwallner]

(In reply to comment #7)
> There's one part of this patch that I question.  
> -        .LEVEL   2.0N
> +        .LEVEL   2.0
> please explain why you're making this change. 
> If it's because gcc doesn't grok 2.0N, then 
> I think you should ifdef this.

Exactly, GNU-as does not understand level "2.0N" - most likely because it isn't mentioned at all in http://docs.hp.com/en/92432-90012/ch04s22.html
As it does not make a difference for the HP assembler actually using either "2.0" or "2.0N", I don't think there's need for an ifdef here.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh, Could you ask Dennis Handly's advice on this patch, too, please?

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

I am targeting this patch for 3.13, because the code is in one of the 
directories of code frozen for FIPS 140.  But since HP platforms are NOT
among our FIPS 140 certified platforms, it is not clear to me that the 
source files to be modified by this patch really are frozen for FIPS. 
I hope my fellow NSS team mates will clarify this soon.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 432347 [details] [diff] [review]
combined patch as a cvs diff

r=nelson

I don't have access to an HP PA-Risc machine on which to test this patch, 
so I'm giving this a "blind review".  The original code was written by 
Bill Ackerman, who was (is) a true PA-Risc wizard.  I was amused by his 
"real men" comments, which are removed here, but I guess their time 
is over.  I see no problems with the changes to the real executable 
instructions.  My only concerns have been with the "pseudo ops". 
I guess that 2.0 (no suffix) is equivalent to 2.0N (for Narrow).
Hopefully GCC understands 2.0W (for Wide) and doesn't treat 2.0 as 2.0W.  

I will commit to the 3.13 branch.  I don't even know if we have any HP 
PA-Risc tinderbox machines that will build this.  If not, then it is 
conceivable this this could break the build (for non GCC builds) and 
we wouldn't know it for a long time.  That would be unfortunate.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Bug 551188: support building nss on hpux with gcc and GNU-as
Patch contributed by Michael Haubenwallner <[e-mail]>

On trunk:
coreconf/HP-UX.mk;            new: 1.16; previous: 1.15  

On 3.13 branch:
nss/lib/freebl/Makefile;      new: 1.108.4.3; previous: 1.108.4.2
nss/lib/freebl/ret_cr16.s;    new: 1.2.56.1; previous: 1.2
nss/lib/freebl/mpi/hpma512.s; new: 1.3.56.1; previous: 1.3
nss/lib/freebl/mpi/hppa20.s;  new: 1.2.56.1; previous: 1.2

Comment 14

[Michael Haubenwallner]

(In reply to comment #12)
> I guess that 2.0 (no suffix) is equivalent to 2.0N (for Narrow).
> Hopefully GCC understands 2.0W (for Wide) and doesn't treat 2.0 as 2.0W.  

Even if it might not count here, but for what I can say: Both these are true.
Thank you anyway!