[gnutls-help] Compiling gnutls on solaris

dev dev at cor0.com
Tue Sep 30 21:55:32 CEST 2014



On September 30, 2014 at 3:15 PM Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Tue, 2014-09-30 at 14:04 -0400, dev wrote:
>
> > > > OKay, this looks familiar and I remember running into this last
> > > > time
> > > > I
> > > > tried a build of gnutls and I think I recall the solution was we
> > > > need
> > > > -lsocket -lnsl on Solaris because the socket funcs inet_ntop,
> > > > inet_ntoa
> > [...]
> > I have made no progress on that yet. There is someplace in that
> > Makefile
> > within the ./lib directory that needs -lnsl and -lsocket but I can
> > not
> > seem to find where. Any hints ?
>
> gnulib may have done some discovery of them. Do any of the variables
> in
> config.log contains -lsocket -lnsl? If yes we could reuse it. I'd have
> expected LIBSOCKET to contain that.

Let me come back to this one in another email. I am going to do a pull
from the git repo and then try again from scratch and see what I see.
Better to work with current data.

>
> > Also, unrelated, but annoying little type mismatch warnings from two
> > source
> > files are easily fixed with a simple cast thus :
> > Warning :
> >   CC       x509.lo
> > "x509.c", line 2954: warning: argument #3 is incompatible with
> > prototype:
> >         prototype: pointer to unsigned int :
> > "./../includes/gnutls/x509-ext.h", line 64
> >         argument : pointer to enum gnutls_x509_subject_alt_name_t
> > {GNUTLS_SAN_OTHERNAME_XMPP(1000), GNUTLS_SAN_DN(6),
> > GNUTLS_SAN_OTHERNAME(5), GNUTLS_SAN_IPADDRESS(4), GNUTLS_SAN_URI(3),
> > GNUTLS_SAN_RFC822NAME(2), GNUTLS_SAN_DNSNAME(1)}
>
> I don't see why that warning is there. The prototype I have has
> "unsigned int", and in the code "type" is defined as unsigned.

The problem seems to  be that the argument should be a ointer to enum
gnutls_x509_subject_alt_name_t but that is not what the actual argument
is. Therefore I chucked in a silly cast to make the warning go away.
However I may be masking a problem that is worth looking at .. not sure.

> Is that from gnutls master? Could you quote the function and the
> prototype you
> have?


Sorry, this was from the release tarball. I am going to do a pull and
get going from scratch and let you know what I see.

> Thanks. I've fixed the prototype instead. Casting functions is pretty
> dangerous.

Thank you.

If you did the commit then I should get a cleaner run on this before I
hit my snag with inet_aton().

Dennis



More information about the Gnutls-help mailing list