Re: -Werror vs. NetBSD

2016-02-04 Thread Martin Thomson 
Yes,  the landing of the first patches for TLS 1.3 was a bit messy.  We are
working on fixing these problems.  We do have a requirement for c99, which
might account for the //comments.  We are trying not to land any of those
though.
On Feb 4, 2016 8:27 PM, "Thomas Klausner"  wrote:

> Hi Martin!
>
> Thanks for the reply.
>
> Yes, of course I can file a bug report for that. I guess I should
> finish the patch first?
>
> For two days now, I see a different build failure though:
>
> gcc -o NetBSD7.99.26_64_OPT.OBJ/tls13hkdf.o -c -O -fPIC -DPIC  -ansi -Wall
> -Wno-switch -pipe -DNETBSD -Dunix -DHAVE_STRERROR -DHAVE_BSD_FLOCK -Wall
> -Werror -DXP_UNIX -UDEBUG -DNDEBUG -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT
> -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -DNSS_ENABLE_SSL_ZLIB
> -I/usr/pkg/include/nspr -I/usr/X11R6/include
> -I./../dist/NetBSD7.99.26_64_OPT.OBJ/include -I./../dist/public/
> -I./../dist/private/ -I/usr/X11R6/include
> -I../../dist/NetBSD7.99.26_64_OPT.OBJ/include -I../../dist/public/
> -I../../dist/private/ -I/usr/X11R6/include
> -I../../../dist/NetBSD7.99.26_64_OPT.OBJ/include -I../../../dist/public/nss
> -I../../../dist/private/nss  tls13hkdf.c
> tls13hkdf.c:15:1: error: expected identifier or '(' before '/' token
>  // TODO(e...@rtfm.com): Export this separately.
>  ^
> tls13hkdf.c:15:12: error: stray '@' in program
>  // TODO(e...@rtfm.com): Export this separately.
> ^
> tls13hkdf.c: In function 'tls13_HkdfExpandLabel':
> tls13hkdf.c:136:5: error: implicit declaration of function
> 'tls13_EncodeUintX' [-Werror=implicit-function-declaration]
>  ptr = tls13_EncodeUintX(keySize, 2, ptr);
>  ^
> tls13hkdf.c:136:9: error: assignment makes pointer from integer without a
> cast [-Werror]
>  ptr = tls13_EncodeUintX(keySize, 2, ptr);
>  ^
> tls13hkdf.c:137:9: error: assignment makes pointer from integer without a
> cast [-Werror]
>  ptr = tls13_EncodeUintX(labelLen + kLabelPrefixLen, 1, ptr);
>  ^
> tls13hkdf.c:142:9: error: assignment makes pointer from integer without a
> cast [-Werror]
>  ptr = tls13_EncodeUintX(handshakeHashLen, 1, ptr);
>  ^
> cc1: all warnings being treated as errors
>
>  Thomas
>
>
> On Mon, Feb 01, 2016 at 11:15:14AM +1100, Martin Thomson wrote:
> > Hi Thomas,
> >
> > Do you think that you could push these patches to bugzilla?  See
> >
> https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=Libraries
> >
> > And it would be easier to review this as a single patch, I think,
> > since all the changes are fairly simple.
> >
> > On Sat, Jan 30, 2016 at 11:40 PM, Thomas Klausner  wrote:
> > > Hi!
> > >
> > > Recently nss turned on -Werror by default for all platforms. I think
> > > that's a good idea. However, it majorly broke the build on NetBSD with
> > > lots of these types of messages:
> > >
> > > certcgi.c: In function 'MakeNameConstraints':
> > > certcgi.c:1654:6: error: array subscript has type 'char'
> [-Werror=char-subscripts]
> > >
> > > The reason is that NetBSD is very picky about the use of the ctype
> > > functions. To cite the man page ctype(3):
> > >
> > > CAVEATS
> > >  The first argument of these functions is of type int, but only a
> very
> > >  restricted subset of values are actually valid.  The argument
> must either
> > >  be the value of the macro EOF (which has a negative value), or
> must be a
> > >  non-negative value within the range representable as unsigned
> char.
> > >  Passing invalid values leads to undefined behavior.
> > >
> > >  Values of type int that were returned by getc(3), fgetc(3), and
> similar
> > >  functions or macros are already in the correct range, and may be
> safely
> > >  passed to these ctype functions without any casts.
> > >
> > >  Values of type char or signed char must first be cast to unsigned
> char,
> > >  to ensure that the values are within the correct range.  Casting a
> > >  negative-valued char or signed char directly to int will produce a
> > >  negative-valued int, which will be outside the range of allowed
> values
> > >  (unless it happens to be equal to EOF, but even that would not
> give the
> > >  desired result).
> > >
> > >
> > > I've started fixing these, attached is a first batch of patches. More
> > > are needed, but I wanted to find out first how to make sure they get
> > > applied.
> > >
> > > I'll also attach two patches for the included zlib. It doesn't compile
> > > because of missing prototypes for read/write/close, so I added an
> > > #include  in two places.
> > >
> > > Thanks,
> > >  Thomas
> > >
> > > --
> > > dev-tech-crypto mailing list
> > > dev-tech-crypto@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-tech-crypto
> > --
> > dev-tech-crypto mailing list
> > dev-tech-crypto@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-tech-crypto
> >
>
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org

Re: -Werror vs. NetBSD

2016-02-04 Thread Thomas Klausner 
Hi Martin!

Thanks for the reply.

Yes, of course I can file a bug report for that. I guess I should
finish the patch first?

For two days now, I see a different build failure though:

gcc -o NetBSD7.99.26_64_OPT.OBJ/tls13hkdf.o -c -O -fPIC -DPIC  -ansi -Wall 
-Wno-switch -pipe -DNETBSD -Dunix -DHAVE_STRERROR -DHAVE_BSD_FLOCK -Wall 
-Werror -DXP_UNIX -UDEBUG -DNDEBUG -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT 
-DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -DNSS_ENABLE_SSL_ZLIB 
-I/usr/pkg/include/nspr -I/usr/X11R6/include 
-I./../dist/NetBSD7.99.26_64_OPT.OBJ/include -I./../dist/public/ 
-I./../dist/private/ -I/usr/X11R6/include 
-I../../dist/NetBSD7.99.26_64_OPT.OBJ/include -I../../dist/public/ 
-I../../dist/private/ -I/usr/X11R6/include 
-I../../../dist/NetBSD7.99.26_64_OPT.OBJ/include -I../../../dist/public/nss 
-I../../../dist/private/nss  tls13hkdf.c
tls13hkdf.c:15:1: error: expected identifier or '(' before '/' token
 // TODO(e...@rtfm.com): Export this separately.
 ^
tls13hkdf.c:15:12: error: stray '@' in program
 // TODO(e...@rtfm.com): Export this separately.
^
tls13hkdf.c: In function 'tls13_HkdfExpandLabel':
tls13hkdf.c:136:5: error: implicit declaration of function 'tls13_EncodeUintX' 
[-Werror=implicit-function-declaration]
 ptr = tls13_EncodeUintX(keySize, 2, ptr);
 ^
tls13hkdf.c:136:9: error: assignment makes pointer from integer without a cast 
[-Werror]
 ptr = tls13_EncodeUintX(keySize, 2, ptr);
 ^
tls13hkdf.c:137:9: error: assignment makes pointer from integer without a cast 
[-Werror]
 ptr = tls13_EncodeUintX(labelLen + kLabelPrefixLen, 1, ptr);
 ^
tls13hkdf.c:142:9: error: assignment makes pointer from integer without a cast 
[-Werror]
 ptr = tls13_EncodeUintX(handshakeHashLen, 1, ptr);
 ^
cc1: all warnings being treated as errors

 Thomas


On Mon, Feb 01, 2016 at 11:15:14AM +1100, Martin Thomson wrote:
> Hi Thomas,
> 
> Do you think that you could push these patches to bugzilla?  See
> https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=Libraries
> 
> And it would be easier to review this as a single patch, I think,
> since all the changes are fairly simple.
> 
> On Sat, Jan 30, 2016 at 11:40 PM, Thomas Klausner  wrote:
> > Hi!
> >
> > Recently nss turned on -Werror by default for all platforms. I think
> > that's a good idea. However, it majorly broke the build on NetBSD with
> > lots of these types of messages:
> >
> > certcgi.c: In function 'MakeNameConstraints':
> > certcgi.c:1654:6: error: array subscript has type 'char' 
> > [-Werror=char-subscripts]
> >
> > The reason is that NetBSD is very picky about the use of the ctype
> > functions. To cite the man page ctype(3):
> >
> > CAVEATS
> >  The first argument of these functions is of type int, but only a very
> >  restricted subset of values are actually valid.  The argument must 
> > either
> >  be the value of the macro EOF (which has a negative value), or must be 
> > a
> >  non-negative value within the range representable as unsigned char.
> >  Passing invalid values leads to undefined behavior.
> >
> >  Values of type int that were returned by getc(3), fgetc(3), and similar
> >  functions or macros are already in the correct range, and may be safely
> >  passed to these ctype functions without any casts.
> >
> >  Values of type char or signed char must first be cast to unsigned char,
> >  to ensure that the values are within the correct range.  Casting a
> >  negative-valued char or signed char directly to int will produce a
> >  negative-valued int, which will be outside the range of allowed values
> >  (unless it happens to be equal to EOF, but even that would not give the
> >  desired result).
> >
> >
> > I've started fixing these, attached is a first batch of patches. More
> > are needed, but I wanted to find out first how to make sure they get
> > applied.
> >
> > I'll also attach two patches for the included zlib. It doesn't compile
> > because of missing prototypes for read/write/close, so I added an
> > #include  in two places.
> >
> > Thanks,
> >  Thomas
> >
> > --
> > dev-tech-crypto mailing list
> > dev-tech-crypto@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-tech-crypto
> -- 
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
> 
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

cross compiling NSS

2016-02-04 Thread Andrew Cagney 
Hi,

I'm trying to understand the "correct" way to cross compile NSS.

The first approach I tried is based on firefox's
config/external/nss/Makefile.in where I found:

ifdef CROSS_COMPILE
DEFAULT_GMAKE_FLAGS += \
NATIVE_CC='$(HOST_CC)' \
CC='$(CC)' \
CCC='$(CXX)' \
LINK='$(LD)' \
AS='$(AS)' \
AR='$(AR) $(AR_FLAGS:$@=$$@)' \
RANLIB='$(RANLIB)' \
RC='$(RC) $(RCFLAGS)' \
OS_ARCH='$(OS_ARCH)' \
OS_TEST='$(OS_TEST)' \
CPU_ARCH='$(TARGET_CPU)' \
$(NULL)

i.e., override both the native compile NATIVE_CC) and cross compiler
(CC) using GNU make command line arguments.  Then, down in
security/nss/coreconf/nsinstall/Makefile (nsinstall needs to be built
native) can use them to set up the native compile vis:

ifdef NATIVE_CC
CC=$(NATIVE_CC)
endif
ifdef NATIVE_FLAGS
OS_CFLAGS=$(NATIVE_FLAGS)
endif

There are two things I'm not understanding with this technique:

- because CC was overridden on the command line, the CC=$(NATIVE_CC)
line gets ignored.  I ended up changing it to:

override CC=$(NATIVE_CC)

- puzzlingly NATIVE_FLAGS is not passed down, and when I did pass them
I found it didn't exactly help  I ended up overriding CFLAGS vis:

ifneq ($(origin NATIVE_FLAGS),undefined)
#override OS_CFLAGS=$(NATIVE_FLAGS)
override CFLAGS=$(NATIVE_FLAGS)
endif


The second technique I've found is to specify OS_TARGET=uClinux-dist
(say), and then add the file nss/coreconf/ucLinux-dist.mk which sets
things up for a cross compile.  With that, the "override" wasn't
needed but the CFLAGS= assignment was.

puzzled,

Andrew
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: cross compiling NSS

2016-02-04 Thread Andrew Cagney 
FYI,

I solved the CFLAGS mystery:

On 4 February 2016 at 10:59, Andrew Cagney  wrote:

> ifdef CROSS_COMPILE
> DEFAULT_GMAKE_FLAGS += \
> NATIVE_CC='$(HOST_CC)' \
> CC='$(CC)' \
> CCC='$(CXX)' \
> LINK='$(LD)' \
> AS='$(AS)' \
> AR='$(AR) $(AR_FLAGS:$@=$$@)' \
> RANLIB='$(RANLIB)' \
> RC='$(RC) $(RCFLAGS)' \
> OS_ARCH='$(OS_ARCH)' \
> OS_TEST='$(OS_TEST)' \
> CPU_ARCH='$(TARGET_CPU)' \
> $(NULL)

If the cross/native compiler's cflags are passed in using OS_CFLAGS
and not simply CFLAGS vis:

OS_CFLAGS=... \
NATIVE_FLAGS=... \

then this almost works:

> ifdef NATIVE_FLAGS
> OS_CFLAGS=$(NATIVE_FLAGS)
> endif

It still needs the "override" and should probably use the more robust
check (for 'NATIVE_CFLAGS='):

ifneq ($(origin NATIVE_FLAGS),undefined)

Andrew
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto