From ametzler at downhill.at.eu.org  Sun Jul  4 14:11:42 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 4 Jul 2010 14:11:42 +0200
Subject: GnuTLS savannah tracker
Message-ID: <20100704121142.GB3347@downhill.g.la>

Hello,
Should bugreports on savannah end up either here or on help-gnutls?

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From simon at josefsson.org  Sun Jul  4 15:38:51 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 04 Jul 2010 15:38:51 +0200
Subject: GnuTLS savannah tracker
In-Reply-To: <20100704121142.GB3347@downhill.g.la> (Andreas Metzler's message
	of "Sun, 4 Jul 2010 14:11:42 +0200")
References: <20100704121142.GB3347@downhill.g.la>
Message-ID: <877hlbe590.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
> Should bugreports on savannah end up either here or on help-gnutls?

I think gnutls-devel is better for anything that may be a bug, but
help-gnutls for anything that is a how-do-I-do-X kind of question.  Are
you thinking of automatic notification or just forwarding a particular
bug manually?

/Simon



From ametzler at downhill.at.eu.org  Sun Jul  4 15:54:24 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 4 Jul 2010 15:54:24 +0200
Subject: GnuTLS savannah tracker
In-Reply-To: <877hlbe590.fsf@mocca.josefsson.org>
References: <20100704121142.GB3347@downhill.g.la>
	<877hlbe590.fsf@mocca.josefsson.org>
Message-ID: <20100704135424.GD3347@downhill.g.la>

On 2010-07-04 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> > Hello,
> > Should bugreports on savannah end up either here or on help-gnutls?

> I think gnutls-devel is better for anything that may be a bug, but
> help-gnutls for anything that is a how-do-I-do-X kind of question.  Are
> you thinking of automatic notification or just forwarding a particular
> bug manually?

I was considering forwarding the whole tracker to the list. It seemed
strange to me that tracker the goes straight to Nikos personal mail
and I was wondering whether this was on oversight or done
intentionally.

cu andreas



From nmav at gnutls.org  Mon Jul  5 08:39:14 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 05 Jul 2010 08:39:14 +0200
Subject: GnuTLS savannah tracker
In-Reply-To: <20100704135424.GD3347@downhill.g.la>
References: <20100704121142.GB3347@downhill.g.la>	<877hlbe590.fsf@mocca.josefsson.org>
	<20100704135424.GD3347@downhill.g.la>
Message-ID: <4C317E12.6020700@gnutls.org>

Andreas Metzler wrote:

> I was considering forwarding the whole tracker to the list. It seemed
> strange to me that tracker the goes straight to Nikos personal mail
> and I was wondering whether this was on oversight or done
> intentionally.

I don't know how to forward the whole tracker to an arbitrary e-mail
address from savanah, that's why it is being sent to me one. If you or
anyone can help on that, you're welcome!

regards,
Nikos



From ametzler at downhill.at.eu.org  Mon Jul  5 19:11:05 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 5 Jul 2010 19:11:05 +0200
Subject: GnuTLS savannah tracker
In-Reply-To: <4C317E12.6020700@gnutls.org>
References: <20100704121142.GB3347@downhill.g.la>
	<877hlbe590.fsf@mocca.josefsson.org>
	<20100704135424.GD3347@downhill.g.la> <4C317E12.6020700@gnutls.org>
Message-ID: <20100705171105.GB3762@downhill.g.la>

On 2010-07-05 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Andreas Metzler wrote:

> > I was considering forwarding the whole tracker to the list. It seemed
> > strange to me that tracker the goes straight to Nikos personal mail
> > and I was wondering whether this was on oversight or done
> > intentionally.

> I don't know how to forward the whole tracker to an arbitrary e-mail
> address from savanah, that's why it is being sent to me one. If you or
> anyone can help on that, you're welcome!

I have not got admin privileges on any savannah tracker, but there
should be any easy way in the admin details for the tracker to add the
list to the "notification list" for the tracker.
cu andreas




From INVALID.NOREPLY at gnu.org  Mon Jul  5 20:14:05 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 05 Jul 2010 18:14:05 +0000
Subject: [sr #107422] test
Message-ID: <20100705-211404.sv707.95262@savannah.gnu.org>


URL:
  <http://savannah.gnu.org/support/?107422>

                 Summary: test
                 Project: GnuTLS
            Submitted by: nmav
            Submitted on: Mon 05 Jul 2010 09:14:04 PM EEST
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

test




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107422>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From simon at josefsson.org  Wed Jul  7 18:02:54 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 Jul 2010 18:02:54 +0200
Subject: GnuTLS savannah tracker
In-Reply-To: <20100705171105.GB3762@downhill.g.la> (Andreas Metzler's message
	of "Mon, 5 Jul 2010 19:11:05 +0200")
References: <20100704121142.GB3347@downhill.g.la>
	<877hlbe590.fsf@mocca.josefsson.org>
	<20100704135424.GD3347@downhill.g.la> <4C317E12.6020700@gnutls.org>
	<20100705171105.GB3762@downhill.g.la>
Message-ID: <87aaq3700h.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2010-07-05 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> Andreas Metzler wrote:
>
>> > I was considering forwarding the whole tracker to the list. It seemed
>> > strange to me that tracker the goes straight to Nikos personal mail
>> > and I was wondering whether this was on oversight or done
>> > intentionally.
>
>> I don't know how to forward the whole tracker to an arbitrary e-mail
>> address from savanah, that's why it is being sent to me one. If you or
>> anyone can help on that, you're welcome!
>
> I have not got admin privileges on any savannah tracker, but there
> should be any easy way in the admin details for the tracker to add the
> list to the "notification list" for the tracker.

As far as I can tell, it is only possible to notify savannah users and
not external mailing lists?  I agree it should be done, but I don't know
how either...

/Simon



From simon at josefsson.org  Wed Jul  7 18:04:36 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 Jul 2010 18:04:36 +0200
Subject: [sr #107422] test
In-Reply-To: <20100705-211404.sv707.95262@savannah.gnu.org> (Nikos
	Mavrogiannopoulos's message of "Mon, 05 Jul 2010 18:14:05 +0000")
References: <20100705-211404.sv707.95262@savannah.gnu.org>
Message-ID: <87630r6zxn.fsf@mocca.josefsson.org>

Ah, so it was possible to notify an external list.  Great!  Thanks Nikos
for making the change.

/Simon



From nmav at gnutls.org  Thu Jul  8 14:57:14 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 8 Jul 2010 14:57:14 +0200
Subject: [sr #107422] test
In-Reply-To: <87630r6zxn.fsf@mocca.josefsson.org>
References: <20100705-211404.sv707.95262@savannah.gnu.org>
	<87630r6zxn.fsf@mocca.josefsson.org>
Message-ID: <AANLkTiloEKmV9I_jW780zOvtC2HKpiG7lABqeEl4vKaA@mail.gmail.com>

On Wed, Jul 7, 2010 at 6:04 PM, Simon Josefsson <simon at josefsson.org> wrote:
> Ah, so it was possible to notify an external list. ?Great! ?Thanks Nikos
> for making the change.

I was also left with the impression that only users can be notified...
I've put the e-mail address and as it seems it works :)
It might be chatty though.

regards,
Nikos



From lfinsto at gwdg.de  Fri Jul  9 11:50:08 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 9 Jul 2010 11:50:08 +0200
Subject: rfc2253-escape-test failed
Message-ID: <5812ce32b2ca06049926479ae51381cf.squirrel@mailbox.gwdg.de>

Hello,

I've just cloned the git repository and built the library.
make and make install succeeded, but I got the following error with make
check:

valgrind: mmap(0x0, 688128) failed in UME with error 13 (Permission denied).
FAIL: rfc2253-escape-test
===================================
1 of 44 tests failed
Please report to bug-gnutls at gnu.org
===================================

However, when I call [...]/gnutls/tests/rfc2253-escape-test directly in a
shell, it returns 0.

I'm using OpenSUSE Linux 11.1.

uname -a
Linux pcfinston 2.6.27.45-0.1-default #1 SMP 2010-02-22 16:49:47 +0100
x86_64 x86_64 x86_64 GNU/Linux

Laurence


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de







From nmav at gnutls.org  Fri Jul  9 16:23:48 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 09 Jul 2010 16:23:48 +0200
Subject: rfc2253-escape-test failed
In-Reply-To: <5812ce32b2ca06049926479ae51381cf.squirrel@mailbox.gwdg.de>
References: <5812ce32b2ca06049926479ae51381cf.squirrel@mailbox.gwdg.de>
Message-ID: <4C3730F4.5020006@gnutls.org>

lfinsto at gwdg.de wrote:
> Hello,
> 
> I've just cloned the git repository and built the library.
> make and make install succeeded, but I got the following error with make
> check:
> 
> valgrind: mmap(0x0, 688128) failed in UME with error 13 (Permission denied).
> FAIL: rfc2253-escape-test
[...]
> However, when I call [...]/gnutls/tests/rfc2253-escape-test directly in a
> shell, it returns 0.

Seems like an error in valgrind. Does running the test with valgrind
succeed?

regards,
Nikos



From simon at josefsson.org  Fri Jul  9 23:31:23 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 09 Jul 2010 23:31:23 +0200
Subject: rfc2253-escape-test failed
In-Reply-To: <5812ce32b2ca06049926479ae51381cf.squirrel@mailbox.gwdg.de>
	(lfinsto@gwdg.de's message of "Fri, 9 Jul 2010 11:50:08 +0200")
References: <5812ce32b2ca06049926479ae51381cf.squirrel@mailbox.gwdg.de>
Message-ID: <87k4p4ibpw.fsf@mocca.josefsson.org>

lfinsto at gwdg.de writes:

> Hello,
>
> I've just cloned the git repository and built the library.
> make and make install succeeded, but I got the following error with make
> check:
>
> valgrind: mmap(0x0, 688128) failed in UME with error 13 (Permission denied).
> FAIL: rfc2253-escape-test
> ===================================
> 1 of 44 tests failed
> Please report to bug-gnutls at gnu.org
> ===================================
>
> However, when I call [...]/gnutls/tests/rfc2253-escape-test directly in a
> shell, it returns 0.

Sounds like a valgrind problem.  Try 'make check VALGRIND=' or
./configure --disable-valgrind-tests.

/Simon



From nmav at gnutls.org  Sat Jul 10 23:44:15 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 10 Jul 2010 23:44:15 +0200
Subject: select + record_recv
Message-ID: <4C38E9AF.2000706@gnutls.org>

In the early versions of GnuTLS I implemented a hack in order to use
select() to check whether there are data to read from the gnutls
session. Is this feature actually used? If you want to check for data in
a gnutls_session how do you do it?


regards,
Nikos



From mrsam at courier-mta.com  Sat Jul 10 22:53:18 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sat, 10 Jul 2010 16:53:18 -0400
Subject: select + record_recv
References: <4C38E9AF.2000706@gnutls.org>
Message-ID: <cone.1278795198.486961.5886.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> In the early versions of GnuTLS I implemented a hack in order to use
> select() to check whether there are data to read from the gnutls
> session. Is this feature actually used? If you want to check for data in
> a gnutls_session how do you do it?

I always thought that the correct logic is:

1) Non-blocking sockets are a must.

2) Check what gnutls_record_check_pending() tells you, first.

23 If there's nothing pending, poll() or select(), and if it indicates that 
data is available, try gnutls_record_recv().

Now, if gnutls_record_recv() hands you back some data, you do have to 
consume it. However, this logic seems to work reliably for me, in 
event-driven situations.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20100710/c74978d5/attachment.pgp>

From nmav at gnutls.org  Sun Jul 11 12:34:21 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 11 Jul 2010 12:34:21 +0200
Subject: select + record_recv
In-Reply-To: <cone.1278795198.486961.5886.500@commodore.email-scan.com>
References: <4C38E9AF.2000706@gnutls.org>
	<cone.1278795198.486961.5886.500@commodore.email-scan.com>
Message-ID: <4C399E2D.7070700@gnutls.org>

Sam Varshavchik wrote:
> Nikos Mavrogiannopoulos writes:
> 
>> In the early versions of GnuTLS I implemented a hack in order to use
>> select() to check whether there are data to read from the gnutls
>> session. Is this feature actually used? If you want to check for data in
>> a gnutls_session how do you do it?
> 
> I always thought that the correct logic is:
> 
> 1) Non-blocking sockets are a must.
> 
> 2) Check what gnutls_record_check_pending() tells you, first.

So do you traverse over all gnutls sessions and use the pending function?

> 23 If there's nothing pending, poll() or select(), and if it indicates
> that data is available, try gnutls_record_recv().
> 
> Now, if gnutls_record_recv() hands you back some data, you do have to
> consume it. However, this logic seems to work reliably for me, in
> event-driven situations.

Indeed this looks to be the correct approach.


regards,
Nikos



From mrsam at courier-mta.com  Sun Jul 11 14:12:04 2010
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Sun, 11 Jul 2010 08:12:04 -0400
Subject: select + record_recv
References: <4C38E9AF.2000706@gnutls.org>
	<cone.1278795198.486961.5886.500@commodore.email-scan.com>
	<4C399E2D.7070700@gnutls.org>
Message-ID: <cone.1278850324.323779.11270.500@commodore.email-scan.com>

Nikos Mavrogiannopoulos writes:

> Sam Varshavchik wrote:
>> Nikos Mavrogiannopoulos writes:
>> 
>>> In the early versions of GnuTLS I implemented a hack in order to use
>>> select() to check whether there are data to read from the gnutls
>>> session. Is this feature actually used? If you want to check for data in
>>> a gnutls_session how do you do it?
>> 
>> I always thought that the correct logic is:
>> 
>> 1) Non-blocking sockets are a must.
>> 
>> 2) Check what gnutls_record_check_pending() tells you, first.
> 
> So do you traverse over all gnutls sessions and use the pending function?

Yes.

> 
>> 23 If there's nothing pending, poll() or select(), and if it indicates
>> that data is available, try gnutls_record_recv().
>> 
>> Now, if gnutls_record_recv() hands you back some data, you do have to
>> consume it. However, this logic seems to work reliably for me, in
>> event-driven situations.
> 
> Indeed this looks to be the correct approach.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20100711/1391baa7/attachment.pgp>

From INVALID.NOREPLY at gnu.org  Mon Jul 12 18:59:22 2010
From: INVALID.NOREPLY at gnu.org (Michael Sweet)
Date: Mon, 12 Jul 2010 16:59:22 +0000
Subject: [sr #107409] The lack of built-in threading support is a critical
	design flaw
In-Reply-To: <20100703-134327.sv707.35926@savannah.gnu.org>
References: <20100624-155547.sv79072.29581@savannah.gnu.org>
	<20100703-133746.sv707.92700@savannah.gnu.org>
	<20100703-134327.sv707.35926@savannah.gnu.org>
Message-ID: <20100712-165922.sv79072.50027@savannah.gnu.org>


Follow-up Comment #2, sr #107409 (project gnutls):

Thanks, will do some testing and get back to you...


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107409>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From simon at josefsson.org  Tue Jul 13 19:13:31 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 13 Jul 2010 19:13:31 +0200
Subject: [SCM] GNU gnutls branch, gnutls_2_10_x,
	updated. gnutls_2_10_0-9-g301635a
In-Reply-To: <E1OWt1M-0004Yd-Uy@vcs-noshell.in.savannah.gnu.org> (Nikos
	Mavrogiannopoulos's message of "Thu, 08 Jul 2010 15:28:16 +0000")
References: <E1OWt1M-0004Yd-Uy@vcs-noshell.in.savannah.gnu.org>
Message-ID: <87zkxv71ac.fsf@mocca.josefsson.org>

"Nikos Mavrogiannopoulos" <nmav at gnutls.org> writes:

> +  gnutls_certificate_set_verify_flags(xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);

What was the reason for this change?  Do we want to do this
unconditionally?  Maybe we could introduce a --permit-v1-cas flag?  I'd
rather prefer to treat V1 CAs as broken-by-default...

Hm.  Generally, X.509 validation is quite complex, just like TLS
security policies.  I wonder if a X.509 priority string concept would be
useful?  Then the user could say --x509-priority
"NORMAL:+VERIFY_ALLOW_X509_V1_CA_CRT" to do the above.  Thoughts?  The
string could be used to modify how X.509 validation works in many ways.

/Simon



From nmav at gnutls.org  Tue Jul 13 19:35:00 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 13 Jul 2010 19:35:00 +0200
Subject: [SCM] GNU gnutls branch, gnutls_2_10_x,
	updated. gnutls_2_10_0-9-g301635a
In-Reply-To: <87zkxv71ac.fsf@mocca.josefsson.org>
References: <E1OWt1M-0004Yd-Uy@vcs-noshell.in.savannah.gnu.org>
	<87zkxv71ac.fsf@mocca.josefsson.org>
Message-ID: <4C3CA3C4.3090702@gnutls.org>

Simon Josefsson wrote:
> "Nikos Mavrogiannopoulos" <nmav at gnutls.org> writes:
> 
>> +  gnutls_certificate_set_verify_flags(xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);
> 
> What was the reason for this change?  Do we want to do this
> unconditionally?  Maybe we could introduce a --permit-v1-cas flag?  I'd
> rather prefer to treat V1 CAs as broken-by-default...

There is no practical problem with having V1 root CAs, the problem is
with the intermediate (untrusted) and this flag allows only root CAs. If
disabled it fails to verify a large fraction of any root CA list. A flag
that would disallow them would offer the functionality you say, but I
don't think it should be the default (not today with this large set of
V1 CAs at least).

> Hm.  Generally, X.509 validation is quite complex, just like TLS
> security policies.  I wonder if a X.509 priority string concept would be
> useful?  Then the user could say --x509-priority
> "NORMAL:+VERIFY_ALLOW_X509_V1_CA_CRT" to do the above.  Thoughts?  The
> string could be used to modify how X.509 validation works in many ways.

There one would like to have some standard validation policies that are
easy to grasp, rather than the complex flags. Maybe combined with a
better verification subsystem than the simple one we have.

regards,
Nikos



From nmav at gnutls.org  Tue Jul 13 19:43:31 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 13 Jul 2010 19:43:31 +0200
Subject: [SCM] GNU gnutls branch, gnutls_2_10_x,
	updated. gnutls_2_10_0-9-g301635a
In-Reply-To: <87zkxv71ac.fsf@mocca.josefsson.org>
References: <E1OWt1M-0004Yd-Uy@vcs-noshell.in.savannah.gnu.org>
	<87zkxv71ac.fsf@mocca.josefsson.org>
Message-ID: <4C3CA5C3.2080707@gnutls.org>

Simon Josefsson wrote:

> What was the reason for this change? 

Check also the discussion in the help-gnutls ML few days ago (5/7).




From lfinsto at gwdg.de  Wed Jul 14 12:01:17 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 14 Jul 2010 12:01:17 +0200
Subject: rfc2253-escape-test failed
Message-ID: <55a36306933dfb98a9adee2ad1cd6336.squirrel@mailbox.gwdg.de>

> Sounds like a valgrind problem.  Try 'make check VALGRIND=' or
> ./configure --disable-valgrind-tests.

I tried this:
./configure --disable-valgrind-tests.

and `make check' worked.

Do the tests using valgrind require root permissions? I'm building GNUTLS
as a normal user and therefore couldn't use `make bootstrap', because it
tries to write to /usr/local/bin, etc.  Since the error was "Permission
denied", I thought that might have something to do with it.

I actually invoked configure like this:

 ./configure --disable-valgrind-tests
--with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.4

because I had to install a newer version of libgcrypt than the most recent
one available for OpenSUSE 11.1, namely 1.4.1-4.1  (x86_64).

However, I got the following error, because there was no `-I' option with
the correct path when `[...]/gnutls/lib/gcrypt/init.c' was compiled:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./../gl -I./../gl
-I./../includes -I./../includes -I./.. -g -O2 -MT init.lo -MD -MP -MF
.deps/init.Tpo -c init.c  -fPIC -DPIC -o .libs/init.o
init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a
function)
make[4]: *** [init.lo] Error 1

I fixed this by copying gcrypt.h and gcrypt-module.h
from /home/lfinsto/libgcrypt-1.4.4/include/ to
`[...]/gnutls/lib/gcrypt/init.c', but this is obviously not a good  solution.

Perhaps it would be useful if I wrote up something to explain how to build
and install GNUTLS as a user without root permissions, but first I would
like to make a branch in the git repository (for this and other purposes).
 I've read some documentation for git, but I haven't quite figured this
out and I don't want to do anything that would mess up the repository.

On the other hand, it wouldn't be necessary if it were possible to pass
appropriate "arguments" to `make bootstrap' (using environment variables,
perhaps).  I've had a quick look at a couple of the Makefile.am files, but
it was not immediately obvious to me how the rules work and what they're
meant to do.

It might also be worthwhile to document  --with-libgcrypt-prefix and
similar arguments to configure in README or READ-alpha.  I wasted some
time fiddling with `CFLAGS', etc., before it occurred to me to read what
`configure --help' output above the description of these variables.


Laurence


On Fri, July 9, 2010 11:31 pm, Simon Josefsson wrote:
> lfinsto at gwdg.de writes:
>> Hello,
>> I've just cloned the git repository and built the library.
>> make and make install succeeded, but I got the following error with
make
>> check:
>> valgrind: mmap(0x0, 688128) failed in UME with error 13 (Permission
denied).
>> FAIL: rfc2253-escape-test
>> ===================================
>> 1 of 44 tests failed
>> Please report to bug-gnutls at gnu.org
>> ===================================
>> However, when I call [...]/gnutls/tests/rfc2253-escape-test directly in
a
>> shell, it returns 0.
> Sounds like a valgrind problem.  Try 'make check VALGRIND=' or
> ./configure --disable-valgrind-tests.
> /Simon


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de









From lfinsto at gwdg.de  Wed Jul 14 12:20:31 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 14 Jul 2010 12:20:31 +0200
Subject: select + record_recv
In-Reply-To: <4C38E9AF.2000706@gnutls.org>
References: <4C38E9AF.2000706@gnutls.org>
Message-ID: <3efbe096ec41e19422b0e79be8aea00d.squirrel@mailbox.gwdg.de>


On Sat, July 10, 2010 11:44 pm, Nikos Mavrogiannopoulos wrote:
> In the early versions of GnuTLS I implemented a hack in order to use
> select() to check whether there are data to read from the gnutls
> session. Is this feature actually used? If you want to check for data in
> a gnutls_session how do you do it?

No, I don't use it, but I probably would have, if I'd known about it.  I
must have missed it in the documentation.

Instead, I've taken some trouble to ensure that the client and server are
"synchronized" in the sense that server always gets a message from the
client when it's waiting for one and vice versa.  In a couple of places,
it's necessary for one or the other to signal the peer to stop waiting. 
It does this by sending a single null byte.  In this case, the message is
not processed.  Otherwise, if there's data, it is passed to the respective
parser function.  The server's parser function has a rule for "Client
finished" and the client's parser function has a rule for "Server
finished".  Normally, the client will end the connection when it's
finished and the server has told the client that it's finished.  Handling
error conditions is somewhat more complicated, but the connection should
never just be broken off.

This approach seems to work well and I wouldn't change it for one that
uses polling at this point. With my application, connections shouldn't
normally be left open for a long time with wide gaps between messages from
one peer to the other.

Laurence


>
>
> regards,
> Nikos
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From lfinsto at gwdg.de  Wed Jul 14 14:18:01 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 14 Jul 2010 14:18:01 +0200
Subject: rfc2253-escape-test failed
In-Reply-To: <55a36306933dfb98a9adee2ad1cd6336.squirrel@mailbox.gwdg.de>
References: <55a36306933dfb98a9adee2ad1cd6336.squirrel@mailbox.gwdg.de>
Message-ID: <5414b491f74c82b49fe4684da8d6e38c.squirrel@mailbox.gwdg.de>


On Wed, July 14, 2010 12:01 pm, lfinsto at gwdg.de wrote:

Sorry, there's a typo in this:

> I fixed this by copying gcrypt.h and gcrypt-module.h
> from /home/lfinsto/libgcrypt-1.4.4/include/ to
> `[...]/gnutls/lib/gcrypt/init.c', but this is obviously not a good
> solution.

I meant copied to `[...]/gnutls/lib/gcrypt/', of course.

Laurence



-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From lfinsto at gwdg.de  Wed Jul 14 15:46:51 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 14 Jul 2010 15:46:51 +0200
Subject: rfc2253-escape-test failed
In-Reply-To: <55a36306933dfb98a9adee2ad1cd6336.squirrel@mailbox.gwdg.de>
References: <55a36306933dfb98a9adee2ad1cd6336.squirrel@mailbox.gwdg.de>
Message-ID: <08373c1f93dd33bf36a9d1edc803a318.squirrel@mailbox.gwdg.de>


I've updated my local copy of the main branch and built the package again.
 I had a couple of problems:

make bootstrap

configure --disable-valgrind-tests
--with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.4 --prefix=`pwd`

Linking failed until I did this:

export LDFLAGS="-L/home/lfinsto/libgcrypt-1.4.4/lib"

i.e., the path passed as the argument to the --with-libgcrypt-prefix
option of configure (plus `/lib') wasn't used in the link command.

It's a bit inconvenient to have to call `configure' after `make
bootstrap', especially since `configure' takes so long to run.  (Very
noticeable when done over and over.)

This also needs to be done, as mentioned previously:

cp /home/lfinsto/libgcrypt-1.4.4/include/*.h ./lib/gcrypt

After that, it's clear sailing, except for this:

Creating man pages for lib/warning: 15446: Cannot understand  * @session:
gnutls session
 on line 15446 - I thought it was a doc line
warning: 15468: Cannot understand  * @session: gnutls session
 on line 15468 - I thought it was a doc line

[...]

It seems to be one error, but there is a total of 1332 lines of error
messages.

Laurence


On Wed, July 14, 2010 12:01 pm, lfinsto at gwdg.de wrote:
>> Sounds like a valgrind problem.  Try 'make check VALGRIND=' or
>> ./configure --disable-valgrind-tests.
>
> I tried this:
> ./configure --disable-valgrind-tests.
>
> and `make check' worked.
>
> Do the tests using valgrind require root permissions? I'm building GNUTLS
> as a normal user and therefore couldn't use `make bootstrap', because it
> tries to write to /usr/local/bin, etc.  Since the error was "Permission
> denied", I thought that might have something to do with it.
>
> I actually invoked configure like this:
>
>  ./configure --disable-valgrind-tests
> --with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.4
>
> because I had to install a newer version of libgcrypt than the most recent
> one available for OpenSUSE 11.1, namely 1.4.1-4.1  (x86_64).
>
> However, I got the following error, because there was no `-I' option with
> the correct path when `[...]/gnutls/lib/gcrypt/init.c' was compiled:
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./../gl -I./../gl
> -I./../includes -I./../includes -I./.. -g -O2 -MT init.lo -MD -MP -MF
> .deps/init.Tpo -c init.c  -fPIC -DPIC -o .libs/init.o
> init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a
> function)
> make[4]: *** [init.lo] Error 1
>
> I fixed this by copying gcrypt.h and gcrypt-module.h
> from /home/lfinsto/libgcrypt-1.4.4/include/ to
> `[...]/gnutls/lib/gcrypt/init.c', but this is obviously not a good
> solution.
>
> Perhaps it would be useful if I wrote up something to explain how to build
> and install GNUTLS as a user without root permissions, but first I would
> like to make a branch in the git repository (for this and other purposes).
>  I've read some documentation for git, but I haven't quite figured this
> out and I don't want to do anything that would mess up the repository.
>
> On the other hand, it wouldn't be necessary if it were possible to pass
> appropriate "arguments" to `make bootstrap' (using environment variables,
> perhaps).  I've had a quick look at a couple of the Makefile.am files, but
> it was not immediately obvious to me how the rules work and what they're
> meant to do.
>
> It might also be worthwhile to document  --with-libgcrypt-prefix and
> similar arguments to configure in README or READ-alpha.  I wasted some
> time fiddling with `CFLAGS', etc., before it occurred to me to read what
> `configure --help' output above the description of these variables.
>
>
> Laurence
>
>
> On Fri, July 9, 2010 11:31 pm, Simon Josefsson wrote:
>> lfinsto at gwdg.de writes:
>>> Hello,
>>> I've just cloned the git repository and built the library.
>>> make and make install succeeded, but I got the following error with
> make
>>> check:
>>> valgrind: mmap(0x0, 688128) failed in UME with error 13 (Permission
> denied).
>>> FAIL: rfc2253-escape-test
>>> ===================================
>>> 1 of 44 tests failed
>>> Please report to bug-gnutls at gnu.org
>>> ===================================
>>> However, when I call [...]/gnutls/tests/rfc2253-escape-test directly in
> a
>>> shell, it returns 0.
>> Sounds like a valgrind problem.  Try 'make check VALGRIND=' or
>> ./configure --disable-valgrind-tests.
>> /Simon
>
>
> -------------------------------------------------------------
> Laurence Finston
> Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
> Am Fassberg 11
> 37077 Goettingen
>
> Telefon: 	+49 551 201-1882
> E-Mail: 	lfinsto at gwdg.de
>
>
>
>
>
>


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From nmav at gnutls.org  Thu Jul 22 19:47:13 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 22 Jul 2010 19:47:13 +0200
Subject: gnutls 2.11.0 released
Message-ID: <4C488421.5000605@gnutls.org>

Hello,

The GnuTLS 2.11.x branch is NOT what you want for your stable system.
It is intended for developers and experienced users.

This is major update release that includes features such as PKCS #11
support for cryptographic objects, support for local system thread
locks, new message buffering layer, support for nettle library and more.

I've uploaded it to the main ftp.gnutls.org. The alpha.gnu.org will
follow soon.

Here are the compressed sources:
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.0.tar.bz2

Here is the OpenPGP signature:
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.0.tar.bz2.sig


regards,
Nikos

* Version 2.11.0 (released 2010-07-22)

** libgnutls: support scattered write using writev(). This takes
advantage of the new buffering layer and allows queuing of packets
and flushing them. This is currently used for handshake messages
only.

** libgnutls: Added gnutls_global_set_mutex() to allow setting
alternative locking procedures. By default the system available
locking is used. In *NIX pthreads are used and in windows the
critical section API. This follows a different approach than the
previous versions that depended on libgcrypt initialization. The
locks are now set by default in systems that support it.

** libgnutls: Added support for reading DN from EV-certificates.
New DN values:
jurisdictionOfIncorporationLocalityName,
jurisdictionOfIncorporationStateOrProvinceName,
jurisdictionOfIncorporationCountryName

** libgnutls: Added support for DSA signing/verifying with bit
length over 1024.

** libgnutls-extra: When in FIPS mode gnutls_global_init_extra()
has to be called to register any required md5 handlers.

** libgnutls: Internal buffering code was replaced by simpler
code contributed by Jonathan Bastien-Filiatrault.

** libgnutls: Internal API for extensions augmented to allow
safe storing and loading of data on resumption. This allows writing
self-contained extensions (when possible). As a side effect
the OPRFI extension was removed.

** libgnutls: Added support for DSA-SHA256 and DSA-SHA224

** libgnutls: Added PKCS #11 support and an API to access objects in
gnutls/pkcs11.h. Currently certificates and public keys can be
imported from tokens, and operations can be performed on private keys.

** libgnutls: Added abstract gnutls_privkey_t and gnutls_pubkey_t

** libgnutls: Added initial support for the nettle library. It uses
the system's random generator for seeding. That is /dev/urandom in
Linux, system calls in Win32 and EGD on other systems.

** libgnutls: Corrected issue on the %SSL3_RECORD_VERSION priority
string. It now works even when resuming a session.

** libgnutls: Added gnutls_certificate_set_retrieve_function() to
replace the similar gnutls_certificate_set_server_retrieve_function()
and gnutls_certificate_set_client_retrieve_function(). In addition it
support PKCS #11 private keys.

** libgnutls: Added  gnutls_pkcs11_copy_x509_crt(),
gnutls_pkcs11_copy_x509_privkey(), and gnutls_pkcs11_delete_url() to
allow copying and deleting data in tokens.

** libgnutls: Added gnutls_sec_param_to_pk_bits() et al. to allow select
bit sizes for private keys using a human understandable scale.

** certtool: Added new options: --pkcs11-list-tokens, --pkcs11-list-all
--pkcs11-list-all-certs, --pkcs11-list-trusted, --pkcs11-list-certs,
--pkcs11-delete-url, --pkcs11-write

certtool: The --pkcs-cipher is taken into account when generating a
private key. The default cipher used now is aes-128. The old behavior
can be simulated by specifying "--pkcs-cipher 3des-pkcs12".

certtool: Added --certificate-pubkey to print the public key of the
certificate.

** gnutls-cli/gnutls-serv: --x509cafile, --x509certfile and --x509keyfile
can now accept a PKCS #11 URL in addition to a file. This will allow for
example to use the Gnome-keyring trusted certificate list to verify
connections using a url such as:
pkcs11:token=Root%20CA%20Certificates;serial=1%3AROOTS%3ADEFAULT;model=1%2E0;manufacturer=Gnome%20Keyring

** API and ABI modifications:
gnutls_certificate_set_server_retrieve_function: DEPRECATED
gnutls_certificate_set_client_retrieve_function: DEPRECATED
gnutls_sign_callback_set: DEPRECATED
gnutls_global_set_mutex: ADDED
gnutls_pubkey_get_preferred_hash_algorithm: ADDED
gnutls_x509_crt_get_preferred_hash_algorithm: ADDED
gnutls_x509_privkey_export_rsa_raw2: ADDED
gnutls_rnd: ADDED
gnutls_sec_param_to_pk_bits: ADDED
gnutls_pk_bits_to_sec_param: ADDED
gnutls_sec_param_get_name: ADDED
gnutls_pkcs11_type_get_name: ADDED
gnutls_certificate_set_retrieve_function: ADDED
gnutls_pkcs11_init: ADDED
gnutls_pkcs11_deinit: ADDED
gnutls_pkcs11_set_pin_function: ADDED
gnutls_pkcs11_set_token_function: ADDED
gnutls_pkcs11_add_provider: ADDED
gnutls_pkcs11_obj_init: ADDED
gnutls_pkcs11_obj_import_url: ADDED
gnutls_pkcs11_obj_export_url: ADDED
gnutls_pkcs11_obj_deinit: ADDED
gnutls_pkcs11_obj_export: ADDED
gnutls_pkcs11_obj_list_import_url: ADDED
gnutls_pkcs11_obj_export: ADDED
gnutls_x509_crt_import_pkcs11: ADDED
gnutls_pkcs11_obj_get_type: ADDED
gnutls_x509_crt_list_import_pkcs11: ADDED
gnutls_x509_crt_import_pkcs11_url: ADDED
gnutls_pkcs11_obj_get_info: ADDED
gnutls_pkcs11_token_get_info: ADDED
gnutls_pkcs11_token_get_url: ADDED
gnutls_pkcs11_privkey_init: ADDED
gnutls_pkcs11_privkey_deinit: ADDED
gnutls_pkcs11_privkey_get_pk_algorithm: ADDED
gnutls_pkcs11_privkey_get_info: ADDED
gnutls_pkcs11_privkey_import_url: ADDED
gnutls_pkcs11_privkey_sign_data: ADDED
gnutls_pkcs11_privkey_sign_hash: ADDED
gnutls_pkcs11_privkey_decrypt_data: ADDED
gnutls_privkey_init: ADDED
gnutls_privkey_deinit: ADDED
gnutls_privkey_get_pk_algorithm: ADDED
gnutls_privkey_get_type: ADDED
gnutls_privkey_import_pkcs11: ADDED
gnutls_privkey_import_x509: ADDED
gnutls_privkey_import_openpgp: ADDED
gnutls_privkey_sign_data: ADDED
gnutls_privkey_sign_hash: ADDED
gnutls_privkey_decrypt_data: ADDED
gnutls_pkcs11_privkey_export_url: ADDED
gnutls_x509_crq_privkey_sign: ADDED
gnutls_x509_crl_privkey_sign: ADDED
gnutls_x509_crt_privkey_sign: ADDED
gnutls_pubkey_init: ADDED
gnutls_pubkey_deinit: ADDED
gnutls_pubkey_get_pk_algorithm: ADDED
gnutls_pubkey_import_x509: ADDED
gnutls_pubkey_import_openpgp: ADDED
gnutls_pubkey_get_pk_rsa_raw: ADDED
gnutls_pubkey_get_pk_dsa_raw: ADDED
gnutls_pubkey_export: ADDED
gnutls_pubkey_get_key_id: ADDED
gnutls_pubkey_get_key_usage: ADDED
gnutls_pubkey_verify_hash: ADDED
gnutls_pubkey_get_verify_algorithm: ADDED
gnutls_pkcs11_type_get_name: ADDED
gnutls_pubkey_import_pkcs11_url: ADDED
gnutls_pubkey_import: ADDED
gnutls_pubkey_import_pkcs11: ADDED
gnutls_pubkey_import_dsa_raw: ADDED
gnutls_pubkey_import_rsa_raw: ADDED
gnutls_x509_crt_set_pubkey: ADDED
gnutls_x509_crq_set_pubkey: ADDED
gnutls_pkcs11_copy_x509_crt: ADDED
gnutls_pkcs11_copy_x509_privkey: ADDED
gnutls_pkcs11_delete_url: ADDED



From arfrever.fta at gmail.com  Thu Jul 22 23:46:50 2010
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 22 Jul 2010 23:46:50 +0200
Subject: gnutls 2.11.0 released
In-Reply-To: <4C488421.5000605@gnutls.org>
References: <4C488421.5000605@gnutls.org>
Message-ID: <201007222347.23081.Arfrever.FTA@gmail.com>

1 test fails:

Making check in sha2
make[2]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
make  sha2 sha2-dsa
make[3]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
make[3]: Nothing to be done for `sha2'.
make[3]: Nothing to be done for `sha2-dsa'.
make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
make  check-TESTS
make[3]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
PASS: sha2
|<2>| ASSERT: pkcs11.c:352
|<2>| Cannot load /etc/gnutls/pkcs11.conf
Generating a signed certificate...
|<2>| ASSERT: x509_b64.c:453
|<2>| Could not find '-----BEGIN RSA PRIVATE KEY'
Setting log level to 2
certtool: reading --load-privkey: ./key-subca-dsa.pem: No such file or directory
FAIL: sha2-dsa
===================================
1 of 2 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests'
make: *** [check-recursive] Error 1

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100722/866652c1/attachment.pgp>

From nmav at gnutls.org  Fri Jul 23 08:11:51 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 23 Jul 2010 08:11:51 +0200
Subject: gnutls 2.11.0 released
In-Reply-To: <201007222347.23081.Arfrever.FTA@gmail.com>
References: <4C488421.5000605@gnutls.org>
	<201007222347.23081.Arfrever.FTA@gmail.com>
Message-ID: <AANLkTinZrz+607R1SRQN+ztMhp-39dWNXUfsbpmFVhwW@mail.gmail.com>

Is this test with nettle? Nettle currently doesn't support SHA224 and
doesn't pass the whole testsuite. However it should work fine, except
for this missing hash.

regards,
Nikos

On Thu, Jul 22, 2010 at 11:46 PM, Arfrever Frehtes Taifersar Arahesis
<arfrever.fta at gmail.com> wrote:
> 1 test fails:
>
> Making check in sha2
> make[2]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
> make ?sha2 sha2-dsa
> make[3]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
> make[3]: Nothing to be done for `sha2'.
> make[3]: Nothing to be done for `sha2-dsa'.
> make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
> make ?check-TESTS
> make[3]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
> PASS: sha2
> |<2>| ASSERT: pkcs11.c:352
> |<2>| Cannot load /etc/gnutls/pkcs11.conf
> Generating a signed certificate...
> |<2>| ASSERT: x509_b64.c:453
> |<2>| Could not find '-----BEGIN RSA PRIVATE KEY'
> Setting log level to 2
> certtool: reading --load-privkey: ./key-subca-dsa.pem: No such file or directory
> FAIL: sha2-dsa
> ===================================
> 1 of 2 tests failed
> Please report to bug-gnutls at gnu.org
> ===================================
> make[3]: *** [check-TESTS] Error 1
> make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
> make[2]: *** [check-am] Error 2
> make[2]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests/sha2'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.11.0/work/gnutls-2.11.0/tests'
> make: *** [check-recursive] Error 1
>
> --
> Arfrever Frehtes Taifersar Arahesis
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>
>



From nmav at gnutls.org  Fri Jul 23 08:23:37 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 23 Jul 2010 08:23:37 +0200
Subject: gnutls 2.11.0 released
In-Reply-To: <201007222347.23081.Arfrever.FTA@gmail.com>
References: <4C488421.5000605@gnutls.org>
	<201007222347.23081.Arfrever.FTA@gmail.com>
Message-ID: <4C493569.1050308@gnutls.org>

On 07/22/2010 11:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:

> Generating a signed certificate...
> |<2>| ASSERT: x509_b64.c:453
> |<2>| Could not find '-----BEGIN RSA PRIVATE KEY'
> Setting log level to 2
> certtool: reading --load-privkey: ./key-subca-dsa.pem: No such file or directory
> FAIL: sha2-dsa

It seems it is not the issue of nettle but rather a missing file. You
can ignore this failure for now, or you can the missing file from the
master.

regards,
Nikos



From lfinsto at gwdg.de  Fri Jul 23 14:25:59 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 23 Jul 2010 14:25:59 +0200
Subject: gnutls 2.11.0 released
Message-ID: <bfaca4b700ca0cbcd8e548b82db7f35d.squirrel@mailbox.gwdg.de>

gnutls 2.11.0 released
From: 	Nikos Mavrogiannopoulos
Subject: 	gnutls 2.11.0 released
Date: 	Thu, 22 Jul 2010 19:47:13 +0200

I got it to build with only minor problems:

As you mentioned in a previous message:

Copied [...]/tests/sha2/key-subca-dsa.pem from master to [...]/gnutls-2.11.0

Then:

configure --disable-valgrind-tests
--with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6 --prefix=`pwd`

make # Fails:

init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a
function)
make[4]: *** [init.lo] Error 1
make[4]: Leaving directory
`/home/lfinsto/gnutls_dev/gnutls-2.11.0/lib/gcrypt'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls-2.11.0/lib'

I mentioned this problem previously with regard to the master, i.e.,
`--with-libgcrypt-prefix' doesn't seem to have the desired effect
everywhere it should.

This didn't work:

export CFLAGS="-I/home/lfinsto/libgcrypt-1.4.6/include"

make # Fails with same error

This did:

ln -s /home/lfinsto/libgcrypt-1.4.6/include/gcrypt.h
/home/lfinsto/gnutls_dev/gnutls-2.11.0/lib/gcrypt/gcrypt.h

make # Succeeds

make install # Succeeds

make check # Succeeds

I ran across another problem when trying to use the master branch of
GNUTLS and libgcrypt 1.4.6, which I have installed as a normal user (and
below this user's home directory) instead of the (outdated) versions of
these libraries provided by OpenSuse 11.1, namely libgcrypt 1.4.1 and
GNUTLS 2.4.1:  `gcry_check_version' needs to be called before any other
libgcrypt functions but after `gcry_control(GCRYCTL_SET_THREAD_CBS, ...)'.
 My application blocked until I added this.

I found a note you'd written in some file (a ChangeLog?) from 2008
explaining this.  I've made a note to myself to find an appropriate place
in the documentation to explain this and also to have a look through the
example programs to see if it should be included in them.  I think it
should be, since I based the parts of my program that use GNUTLS on a
couple of these example programs.

Laurence

-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From nmav at gnutls.org  Fri Jul 23 20:24:39 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 23 Jul 2010 20:24:39 +0200
Subject: gnutls 2.11.0 released
In-Reply-To: <bfaca4b700ca0cbcd8e548b82db7f35d.squirrel@mailbox.gwdg.de>
References: <bfaca4b700ca0cbcd8e548b82db7f35d.squirrel@mailbox.gwdg.de>
Message-ID: <4C49DE67.7030907@gnutls.org>

On 07/23/2010 02:25 PM, lfinsto at gwdg.de wrote:
> gnutls 2.11.0 released
> From: 	Nikos Mavrogiannopoulos
> Subject: 	gnutls 2.11.0 released
> Date: 	Thu, 22 Jul 2010 19:47:13 +0200
> 
> I got it to build with only minor problems:
> 
> As you mentioned in a previous message:
> 
> Copied [...]/tests/sha2/key-subca-dsa.pem from master to [...]/gnutls-2.11.0
> 
> Then:
> 
> configure --disable-valgrind-tests
> --with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6 --prefix=`pwd`

Hi,
 Probably something is wrong with the order of the -I directives. If you
can debug and find some hint on the issue, would be nice. Better check
to see what the issue is on Makefile first.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sat Jul 24 13:00:33 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Jul 2010 11:00:33 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100709-092256.sv0.62113@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
Message-ID: <20100724-140033.sv707.73772@savannah.gnu.org>


Follow-up Comment #1, sr #107424 (project gnutls):

Could you please attach the certificates with the problem so we can verify
the issue?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Jul 24 13:45:33 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Sat, 24 Jul 2010 11:45:33 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100724-140033.sv707.73772@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
	<20100724-140033.sv707.73772@savannah.gnu.org>
Message-ID: <20100724-114533.sv0.57366@savannah.gnu.org>


Additional Item Attachment, sr #107424 (project gnutls):

File name: test.cer                       Size:1 KB
File name: test.key                       Size:1 KB
File name: test.pem                       Size:3 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Jul 24 13:46:46 2010
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Sat, 24 Jul 2010 11:46:46 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100724-114533.sv0.57366@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
	<20100724-140033.sv707.73772@savannah.gnu.org>
	<20100724-114533.sv0.57366@savannah.gnu.org>
Message-ID: <20100724-114646.sv0.39448@savannah.gnu.org>


Follow-up Comment #2, sr #107424 (project gnutls):

Hello!

I uploaded key, cert & pem file so you can test it.


Sincerely,
Gour


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Jul 24 14:06:56 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Jul 2010 12:06:56 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100724-114646.sv0.39448@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
	<20100724-140033.sv707.73772@savannah.gnu.org>
	<20100724-114533.sv0.57366@savannah.gnu.org>
	<20100724-114646.sv0.39448@savannah.gnu.org>
Message-ID: <20100724-150656.sv707.4093@savannah.gnu.org>


Follow-up Comment #3, sr #107424 (project gnutls):

What is the issue with them? I can read them properly by using certtool. It's
just a typical certificate.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Jul 24 16:07:19 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Jul 2010 14:07:19 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100724-133411.sv0.62195@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
	<20100724-140033.sv707.73772@savannah.gnu.org>
	<20100724-114533.sv0.57366@savannah.gnu.org>
	<20100724-114646.sv0.39448@savannah.gnu.org>
	<20100724-150656.sv707.4093@savannah.gnu.org>
	<20100724-133411.sv0.62195@savannah.gnu.org>
Message-ID: <20100724-170719.sv707.59427@savannah.gnu.org>


Follow-up Comment #5, sr #107424 (project gnutls):

So I suppose in your code you do:
  ret = gnutls_x509_privkey_import (tmpkey, raw_key, type);

to import the key. I suggest to add
  /* If normal key decoding doesn't work try decoding a PKCS #8 key */
  if (ret < 0)
    ret = gnutls_x509_privkey_import_pkcs8 (tmpkey, raw_key, type,
                      NULL, GNUTLS_PKCS_PLAIN);


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Jul 24 23:17:23 2010
From: INVALID.NOREPLY at gnu.org (Sebastien Helleu)
Date: Sat, 24 Jul 2010 21:17:23 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100724-170719.sv707.59427@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
	<20100724-140033.sv707.73772@savannah.gnu.org>
	<20100724-114533.sv0.57366@savannah.gnu.org>
	<20100724-114646.sv0.39448@savannah.gnu.org>
	<20100724-150656.sv707.4093@savannah.gnu.org>
	<20100724-133411.sv0.62195@savannah.gnu.org>
	<20100724-170719.sv707.59427@savannah.gnu.org>
Message-ID: <20100724-231723.sv8049.88151@savannah.gnu.org>


Follow-up Comment #6, sr #107424 (project gnutls):

Hi Nikos,

Our problem is with WeeChat, but in our bug report, it's problem with
gnutls-cli command. How can you explain this error? Perhaps we're giving wrong
arguments to gnutls-cli?

For me, there's a difference in files generated with openssl 0.9.x and
openssl 1.0.0. But I don't know enough these files to say what exactly has
changed.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Jul 25 09:29:06 2010
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Jul 2010 07:29:06 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100724-231723.sv8049.88151@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
	<20100724-140033.sv707.73772@savannah.gnu.org>
	<20100724-114533.sv0.57366@savannah.gnu.org>
	<20100724-114646.sv0.39448@savannah.gnu.org>
	<20100724-150656.sv707.4093@savannah.gnu.org>
	<20100724-133411.sv0.62195@savannah.gnu.org>
	<20100724-170719.sv707.59427@savannah.gnu.org>
	<20100724-231723.sv8049.88151@savannah.gnu.org>
Message-ID: <20100725-102906.sv707.96805@savannah.gnu.org>


Follow-up Comment #7, sr #107424 (project gnutls):

The format changed to PKCS #8 encoding. GnuTLS supports it but
requires different function calls to import those keys. The issue with
gnutls-cli will be solved on the next gnutls release. My recommendation was
for a fix that you can apply to your program and not depending on a new gnutls
release.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Jul 25 12:56:12 2010
From: INVALID.NOREPLY at gnu.org (Sebastien Helleu)
Date: Sun, 25 Jul 2010 10:56:12 +0000
Subject: [sr #107424] gnutls cannot handle openssl-1.0.o.a certs
In-Reply-To: <20100725-102906.sv707.96805@savannah.gnu.org>
References: <20100709-092256.sv0.62113@savannah.gnu.org>
	<20100724-140033.sv707.73772@savannah.gnu.org>
	<20100724-114533.sv0.57366@savannah.gnu.org>
	<20100724-114646.sv0.39448@savannah.gnu.org>
	<20100724-150656.sv707.4093@savannah.gnu.org>
	<20100724-133411.sv0.62195@savannah.gnu.org>
	<20100724-170719.sv707.59427@savannah.gnu.org>
	<20100724-231723.sv8049.88151@savannah.gnu.org>
	<20100725-102906.sv707.96805@savannah.gnu.org>
Message-ID: <20100725-125611.sv8049.45042@savannah.gnu.org>


Follow-up Comment #8, sr #107424 (project gnutls):

Thank you Nikos, it's now working in WeeChat with your tip.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107424>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From simon at josefsson.org  Sun Jul 25 13:59:08 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 25 Jul 2010 13:59:08 +0200
Subject: GnuTLS 2.10.1 released
Message-ID: <87d3ub7oxf.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.10.1.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed
under the GNU Free Documentation License version 1.3 (or later).

The project page of the library is available at:
  http://www.gnu.org/software/gnutls/

What's New
==========

** libgnutls: Added support for broken certificates that indicate RSA
with strange OIDs.

** gnutls-cli: Allow verification using V1 CAs.

** libgnutls: gnutls_x509_privkey_import() will fallback to
gnutls_x509_privkey_import_pkcs8() without a password, if it
is unable to decode the key.

** libgnutls: Correctly deinitialize crypto API functions to prevent
a memory leak. Reported by Mads Kiilerich.

** certtool: If asked to generate DSA keys of size more than 1024 bits,
issue a warning, that the output key might not be working everywhere.

** certtool: The --pkcs-cipher is taken into account when generating a
private key. The default cipher used now is aes-128. The old behavior can
be simulated by specifying "--pkcs-cipher 3des-pkcs12".

** API and ABI modifications:
No changes since last version.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (7.2MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.1.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.10.1.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2011-03-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

507ff8ad7c1e042f8ecaa4314f32777e74caf0d3  gnutls-2.10.1.tar.bz2

4024b69acc70cb7e105742f8ad26bf68b7dc0e07657efbbaaf23d0bd  gnutls-2.10.1.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  HTML: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html
  PDF: http://www.gnu.org/software/gnutls/reference/gnutls.pdf

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer
contains libgpg-error v1.8, libgcrypt v1.4.6, libtasn1 v2.7, and
GnuTLS v2.10.1.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.10.1.exe (17MB)
  http://josefsson.org/gnutls4win/gnutls-2.10.1.exe.sig

The checksum values for SHA-1 and SHA-224 are:

f4f0c86ef9761c65941fc53713d17938ac450b3c  gnutls-2.10.1.exe

cd2f69c8e271e26187cb3e64dc179df5f28e8d1b7e5f9d97a7e222fc  gnutls-2.10.1.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.10.1.zip (5.6MB)
  http://josefsson.org/gnutls4win/gnutls-2.10.1.zip.sig

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.7.10-1_all.deb (5.0MB)

The checksum values for SHA-1 and SHA-224 are:

fb6dbcabe30010e761c47589ef86869fb21f82be  gnutls-2.10.1.zip

3a2b2457836dca9e1f8af86101d9a434a966abc544db1493c22797e4  gnutls-2.10.1.zip

0ff1c0c1ded86a5054dd7bcd7b29629afe3169a9  mingw32-gnutls_2.10.1-1_all.deb

066502f2fae542e6c80433090070ef46f02e5a71c80ca4f53b450ac9  mingw32-gnutls_2.10.1-1_all.deb

Internationalization
====================

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Italian, Malay, Polish, Simplified Chinese, Swedish,
and Vietnamese.  We welcome the addition of more translations.

Support
=======

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20100725/444650af/attachment.pgp>

From lfinsto at gwdg.de  Wed Jul 28 17:25:08 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Wed, 28 Jul 2010 17:25:08 +0200
Subject: gnutls 2.11.0 released
In-Reply-To: <4C49DE67.7030907@gnutls.org>
References: <bfaca4b700ca0cbcd8e548b82db7f35d.squirrel@mailbox.gwdg.de>
	<4C49DE67.7030907@gnutls.org>
Message-ID: <e60e8cce18fcad2207b5f09ed0ccae93.squirrel@mailbox.gwdg.de>


On Fri, July 23, 2010 8:24 pm, Nikos Mavrogiannopoulos wrote:

>  Probably something is wrong with the order of the -I directives. If you
> can debug and find some hint on the issue, would be nice. Better check
> to see what the issue is on Makefile first.

This has turned out to be not so easy.  I've spent today trying to find
the variable where the path for the libgcrypt library is stored.  When
I've found it, I can try to get it passed to where it needs to be.

In the course of trying to figure things out, I've tried
make maintainer-clean
aclocal
autoconf
autoheader
etc.

It didn't work with the versions of Autoconf and Automake available for
OpenSuse 11.1, so I installed the most recent stable versions:

autoconf (GNU Autoconf) 2.66
automake (GNU automake) 1.11.1

aclocal must be called like this:
aclocal -I m4 -I gl/m4 -I lib/gl/m4 -I libextra/gl/m4 -I lib/m4 -I
libextra/m4

There may well be some way of telling aclocal where to look, but I haven't
check this yet.

One gets this error:

configure.ac:66: error: AC_CHECK_SIZEOF: requires literal arguments
../../lib/autoconf/types.m4:765: AC_CHECK_SIZEOF is expanded from...
lib/m4/hooks.m4:23: LIBGNUTLS_HOOKS is expanded from...
configure.ac:66: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1

The problem can be solved by the following patch for [...]/lib/m4/hooks.m4.

Briefly, `AC_CHECK_SIZEOF(void *)' doesn't work, although I think it
should, from what the Autoconf manual says.  Nor does
`AC_CHECK_SIZEOF(sizeof(void *))' nor any of the variants I tried, so I've
commented it out.

I've added calls to `AC_TYPE_UINTPTR_T' to and `AC_TYPE_INTPTR_T', which
define appropriate types, if needed.  `SIZEOF_VOID_P' isn't used anywhere
and the package builds correctly.

This applies to the master branch as well as gnutls 2.11.0;
[...]/lib/m4/hooks.m4 is identical in the two versions.

Laurence

**********************************************************

The patch:

diff --git a/m4/hooks.m4 b/m4/hooks.m4
index 378c94a..3a6a086 100644
--- a/m4/hooks.m4
+++ b/m4/hooks.m4
@@ -303,9 +303,12 @@ AC_DEFUN([LIBGNUTLS_HOOKS],

   # For storing integers in pointers without warnings
   #
http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html#desc
-  AC_CHECK_SIZEOF(void *)
-  AC_CHECK_SIZEOF(long)
-  AC_CHECK_SIZEOF(int)
+#  AC_CHECK_SIZEOF([void *])
+  AC_TYPE_UINTPTR_T
+  AC_TYPE_INTPTR_T
+#  AC_CHECK_SIZEOF([sizeof(int*)])
+  AC_CHECK_SIZEOF([long int])
+  AC_CHECK_SIZEOF([int])
   case $ac_cv_sizeof_void_p in
     $ac_cv_sizeof_long)
       AC_DEFINE([GNUTLS_POINTER_TO_INT_CAST], [(long)],


**********************************************************

> On 07/23/2010 02:25 PM, lfinsto at gwdg.de wrote:
>> gnutls 2.11.0 released
>> From: 	Nikos Mavrogiannopoulos
>> Subject: 	gnutls 2.11.0 released
>> Date: 	Thu, 22 Jul 2010 19:47:13 +0200
>>
>> I got it to build with only minor problems:
>>
>> As you mentioned in a previous message:
>>
>> Copied [...]/tests/sha2/key-subca-dsa.pem from master to
>> [...]/gnutls-2.11.0
>>
>> Then:
>>
>> configure --disable-valgrind-tests
>> --with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6 --prefix=`pwd`
>
> Hi,
>  Probably something is wrong with the order of the -I directives. If you
> can debug and find some hint on the issue, would be nice. Better check
> to see what the issue is on Makefile first.
>
> regards,
> Nikos
>


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From lfinsto at gwdg.de  Thu Jul 29 15:36:08 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Thu, 29 Jul 2010 15:36:08 +0200
Subject: master branch --- build problems
Message-ID: <69cac3d9eae49b7bda388c6904114e85.squirrel@mailbox.gwdg.de>


Hello,

After installing the most recent stable releases of autoconf, automake and
libtool:

autoconf (GNU Autoconf) 2.66
automake (GNU automake) 1.11.1
libtool (GNU libtool) 2.2.10

I had considerable difficulty getting the master branch to build, but I
finally succeeded, though I had to comment some things out, which isn't so
good.

The patch below contains the changes I had to make in existing files, but
that was only part of it.

In /lib/Makefile.am, I had to remove `po' from SUBDIRS.  The error that I
got when it was included was this:

config.status: error: cannot find input file: `po/Makefile.in.in'
configure: error: ./configure failed for lib

There was no Makefile, Makefile.in or Makefile.in.in in this directory.
After `touch Makefile.in.in', the others were generated (they were empty).
However, later I got this error:

Making all in po
make[4]: Entering directory `/home/lfinsto/gnutls_dev/gnutls_master/lib/po'
make[4]: *** No rule to make target `all'.  Stop.

Since I don't know that this is about, except that it seems to have
something to do with documentation, I just removed po from SUBDIRS.
In addition, I had to comment-out the calls to `AM_GNU_GETTEXT' in
`/lib/configure.ac'.

The `build-aux' directories were another problem.  In order to generate
the needed files, I had to call `libtoolize' in the top build directory,
/lib/ and /libextra.  Then aclocal with multiple `-I' options for the
various `m4' directories, autoconf, autoheader, automake --add-missing
--copy and configure in each of these directories.  (Perhaps autoheader is
only necessary in the top build directory, I don't know.)

I had to correct the file permissions of the in `build-aux' directories by
hand, because they were not readable by the user.  I don't know why this
should be so.

In /lib/m4/hooks.m4, I had to comment-out this macro invocation (as
mentioned previously):

+  #AC_CHECK_SIZEOF(void *)

Of course, I still needed to call
export LDFLAGS="-L/home/lfinsto/libgcrypt-1.4.6/lib"
even though I used
--with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6
since I haven't been able to solve this problem yet.

For more-or-less the same reason, this is still needed, too:

ln -s /home/lfinsto/libgcrypt-1.4.6/include/gcrypt.h /home/lfinsto

This is the error message I get without it:

/gnutls_dev/gnutlsmake[4]: Entering directory
`/home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt'
  CC     init.lo

init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a
function)
make[4]: *** [init.lo] Error 1
make[4]: Leaving directory
`/home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt'_master/lib/gcrypt/gcrypt.h

There a quite a few warnings like this:

gaa.skel:593: warning: call to 'fseek' declared with attribute warning:
fseek cannot handle files larger than 4 GB on 32-bit platforms - use
fseeko function for handling of large files

I suspect that they're not important, unless the files can be huge for
some reason.

Lots of warnings like this one:

serv.c:1163: warning: cast to pointer from integer of different size

It would probably be worthwhile going through and trying to get rid of
them.  I've had a look, but it was a case of data types referring to other
data types and not obvious to an outsider what's going on.

The last problem was with the Guile bindings.  I had to call `configure'
(in the top build directory) with the option `--disable-guile', because of
the following error, which occurred when `make install' was invoked (but
not previously when `make' was invoked):

libtool: install: (cd /home/lfinsto/gnutls_dev/gnutls_master/guile/src;
/bin/sh /home/lfinsto/gnutls_dev/gnutls_master/libtool  --silent --tag CC
--mode=relink gcc -std=gnu99 -Wno-strict-prototypes -I../../lib/gl
-I../../lib/gl -pthread -g -O2 -L/home/lfinsto/libgcrypt-1.4.6/lib -o
libguile-gnutls-extra-v-1.la -rpath
/home/lfinsto/gnutls_dev/gnutls_master/lib
libguile_gnutls_extra_v_1_la-extra.lo ../../lib/libgnutls.la
../../libextra/libgnutls-extra.la ./libguile-gnutls-v-1.la
../../lib/gl/liblgnu.la -pthread -lguile -lltdl -L/usr/lib64 -lgmp -lcrypt
-lm -lltdl -ldl -lpthread )
libtool: relink: warning: `/usr/lib64/libltdl.la' seems to be moved
libtool: relink: warning: `/usr/lib64/libltdl.la' seems to be moved
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/libltdl.a(libltdl_libltdl_la-ltdl.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/usr/lib64/libltdl.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
libtool: install: error: relink `libguile-gnutls-extra-v-1.la' with the
above command before installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
make[4]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/guile/src'

Apparently, the Guile library was built with the old libltdl from the
OpenSuse RPM and I would need to rebuild it using the newer one I've
installed.  However, I think I will just deinstall the Guile library and
get the most recent version of it.

Would you possibly consider checking `configure', the `Makefile.in' files,
the contents of the `build-aux' directories and other generated files into
the repository?  That way one (with a bit of luck) could at least get the
version in the master branch to build without having to jump through too
many hoops.

I would also be interested to know what versions of autoconf, automake and
libtool you have installed on the systems you're using.  I assume
everything works together smoothly  on your systems.

One problem I ran into was these macro invocations in the top-level
configure.ac:

AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL

This is from the libtool manual (for version 2.2.10):

 -- Macro: LT_INIT (OPTIONS)
 -- Macro: AC_PROG_LIBTOOL
 -- Macro: AM_PROG_LIBTOOL
     Add support for the `--enable-shared' and `--disable-shared'
     `configure' flags.(1)  `AC_PROG_LIBTOOL' and `AM_PROG_LIBTOOL' are
     deprecated names for older versions of this macro; `autoupdate'
     will upgrade your `configure.ac' files.

Before I installed libtool 2.2.10, I got an error because of
AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL.  I didn't get an error when I
called LT_INIT, but the variable LIBTOOL wasn't defined and `configure'
failed, unless it was `make' --- unfortunately, I didn't save this error.

This, on the other hand, is from the Automake manual  (version 1.11.1, 8
December 2009):

`AC_PROG_LIBTOOL'
     Automake will turn on processing for `libtool' (*note
     Introduction: (libtool)Top.).

LT_INIT isn't documented in this manual.  So, it would seem that Autoconf,
Automake, and Libtool, or at least their most recent stable versions, are
not perfectly synchronized with respect to these macros and it was rather
frustrating trying to get `configure' and `make' to run, until it finally
occurred to me to install a newer version of libtool.  However, since
AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL are deprecated, I think it would
be better to use LT_INIT instead.  I've made a note to myself to try this,
now that I've got the package to build.

Laurence

-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de



diff --git a/lib/Makefile.am b/lib/Makefile.am
index 13531d9..dc6ada3 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -23,7 +23,7 @@

 ACLOCAL_AMFLAGS = -I m4 -I gl/m4

-SUBDIRS = gl po includes x509
+SUBDIRS = gl includes x509 #po
 if ENABLE_MINITASN1
 SUBDIRS += minitasn1
 endif
diff --git a/lib/build-aux/config.rpath b/lib/build-aux/config.rpath
index c547c68..17298f2 100755
--- a/lib/build-aux/config.rpath
+++ b/lib/build-aux/config.rpath
@@ -2,7 +2,7 @@
 # Output a system dependent set of variables, describing how to set the
 # run time search path of shared libraries in an executable.
 #
-#   Copyright 1996-2007 Free Software Foundation, Inc.
+#   Copyright 1996-2010 Free Software Foundation, Inc.
 #   Taken from GNU libtool, 2001
 #   Originally by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996
 #
@@ -47,7 +47,7 @@ for cc_temp in $CC""; do
 done
 cc_basename=`echo "$cc_temp" | sed -e 's%^.*/%%'`

-# Code taken from libtool.m4's AC_LIBTOOL_PROG_COMPILER_PIC.
+# Code taken from libtool.m4's _LT_COMPILER_PIC.

 wl=
 if test "$GCC" = yes; then
@@ -64,7 +64,7 @@ else
           ;;
       esac
       ;;
-    mingw* | cygwin* | pw32* | os2*)
+    mingw* | cygwin* | pw32* | os2* | cegcc*)
       ;;
     hpux9* | hpux10* | hpux11*)
       wl='-Wl,'
@@ -76,7 +76,13 @@ else
       ;;
     linux* | k*bsd*-gnu)
       case $cc_basename in
-        icc* | ecc*)
+        ecc*)
+          wl='-Wl,'
+          ;;
+        icc* | ifort*)
+          wl='-Wl,'
+          ;;
+        lf95*)
           wl='-Wl,'
           ;;
         pgcc | pgf77 | pgf90)
@@ -124,7 +130,7 @@ else
   esac
 fi

-# Code taken from libtool.m4's AC_LIBTOOL_PROG_LD_SHLIBS.
+# Code taken from libtool.m4's _LT_LINKER_SHLIBS.

 hardcode_libdir_flag_spec=
 hardcode_libdir_separator=
@@ -132,7 +138,7 @@ hardcode_direct=no
 hardcode_minus_L=no

 case "$host_os" in
-  cygwin* | mingw* | pw32*)
+  cygwin* | mingw* | pw32* | cegcc*)
     # FIXME: the MSVC++ port hasn't been tested in a loooong time
     # When not using gcc, we currently assume that we are using
     # Microsoft Visual C++.
@@ -158,7 +164,7 @@ if test "$with_gnu_ld" = yes; then
   # option of GNU ld is called -rpath, not --rpath.
   hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
   case "$host_os" in
-    aix3* | aix4* | aix5*)
+    aix[3-9]*)
       # On AIX/PPC, the GNU linker is very broken
       if test "$host_cpu" != ia64; then
         ld_shlibs=no
@@ -182,7 +188,7 @@ if test "$with_gnu_ld" = yes; then
         ld_shlibs=no
       fi
       ;;
-    cygwin* | mingw* | pw32*)
+    cygwin* | mingw* | pw32* | cegcc*)
       # hardcode_libdir_flag_spec is actually meaningless, as there is
       # no search path for DLLs.
       hardcode_libdir_flag_spec='-L$libdir'
@@ -254,7 +260,7 @@ else
         hardcode_direct=unsupported
       fi
       ;;
-    aix4* | aix5*)
+    aix[4-9]*)
       if test "$host_cpu" = ia64; then
         # On IA64, the linker does run time linking by default, so we don't
         # have to do anything special.
@@ -264,7 +270,7 @@ else
         # Test if we are trying to use run time linking or normal
         # AIX style linking. If -brtl is somewhere in LDFLAGS, we
         # need to do runtime linking.
-        case $host_os in aix4.[23]|aix4.[23].*|aix5*)
+        case $host_os in aix4.[23]|aix4.[23].*|aix[5-9]*)
           for ld_flag in $LDFLAGS; do
             if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl");
then
               aix_use_runtimelinking=yes
@@ -326,7 +332,7 @@ else
       ;;
     bsdi[45]*)
       ;;
-    cygwin* | mingw* | pw32*)
+    cygwin* | mingw* | pw32* | cegcc*)
       # When not using gcc, we currently assume that we are using
       # Microsoft Visual C++.
       # hardcode_libdir_flag_spec is actually meaningless, as there is
@@ -494,7 +500,7 @@ else
 fi

 # Check dynamic linker characteristics
-# Code taken from libtool.m4's AC_LIBTOOL_SYS_DYNAMIC_LINKER.
+# Code taken from libtool.m4's _LT_SYS_DYNAMIC_LINKER.
 # Unlike libtool.m4, here we don't care about _all_ names of the library,
but
 # only about the one the linker finds when passed -lNAME. This is the last
 # element of library_names_spec in libtool.m4, or possibly two of them if
the
@@ -505,7 +511,7 @@ case "$host_os" in
   aix3*)
     library_names_spec='$libname.a'
     ;;
-  aix4* | aix5*)
+  aix[4-9]*)
     library_names_spec='$libname$shrext'
     ;;
   amigaos*)
@@ -517,7 +523,7 @@ case "$host_os" in
   bsdi[45]*)
     library_names_spec='$libname$shrext'
     ;;
-  cygwin* | mingw* | pw32*)
+  cygwin* | mingw* | pw32* | cegcc*)
     shrext=.dll
     library_names_spec='$libname.dll.a $libname.lib'
     ;;
diff --git a/lib/configure.ac b/lib/configure.ac
index 80dd99e..2fa2bc4 100644
--- a/lib/configure.ac
+++ b/lib/configure.ac
@@ -38,8 +38,8 @@ AC_PROG_LIBTOOL

 LIBGNUTLS_HOOKS

-AM_GNU_GETTEXT([external])
-AM_GNU_GETTEXT_VERSION([0.17])
+#AM_GNU_GETTEXT([external])
+#AM_GNU_GETTEXT_VERSION([0.17])

 AC_C_BIGENDIAN

diff --git a/lib/m4/hooks.m4 b/lib/m4/hooks.m4
index 86d7869..ada9d1d 100644
--- a/lib/m4/hooks.m4
+++ b/lib/m4/hooks.m4
@@ -304,7 +304,7 @@ AC_DEFUN([LIBGNUTLS_HOOKS],

   # For storing integers in pointers without warnings
   #
http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html#desc
-  AC_CHECK_SIZEOF(void *)
+  #AC_CHECK_SIZEOF(void *)
   AC_CHECK_SIZEOF(long)
   AC_CHECK_SIZEOF(int)
   case $ac_cv_sizeof_void_p in






From lfinsto at gwdg.de  Thu Jul 29 16:07:37 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Thu, 29 Jul 2010 16:07:37 +0200
Subject: master branch --- build problems
Message-ID: <e0b97f87f41555e05c3e19fdff7e72ab.squirrel@mailbox.gwdg.de>


On Thu, July 29, 2010 3:36 pm, lfinsto at gwdg.de wrote:

> The `build-aux' directories were another problem.  In order to generate
> the needed files, I had to call `libtoolize' in the top build directory,
> /lib/ and /libextra.  Then aclocal with multiple `-I' options for the
> various `m4' directories, autoconf, autoheader, automake --add-missing
> --copy and configure in each of these directories.  (Perhaps autoheader is
> only necessary in the top build directory, I don't know.)
>
> I had to correct the file permissions of the in `build-aux' directories by
> hand, because they were not readable by the user.  I don't know why this
> should be so.

I forgot to mention that I copied the shellscripts from /build-aux/ to
/lib/build-aux and /libextra/build-aux by hand.  This is definitely not
ideal.


> One problem I ran into was these macro invocations in the top-level
> configure.ac:
>
> AC_LIBTOOL_WIN32_DLL
> AC_PROG_LIBTOOL
>
> However, since
> AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL are deprecated, I think it would
> be better to use LT_INIT instead.  I've made a note to myself to try this,
> now that I've got the package to build.


I've tried it, and it works to replace

AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL

with

LT_INIT([win32-dll])

I called `make clean' and `configure' to be sure.  I'm afraid `make
maintainer-clean' might delete too much and I don't want to risk it right
now.

I've also just tried linking my application to the "master" version of the
library and running it, and that works, too.


Laurence



> -------------------------------------------------------------
> Laurence Finston
> Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
> Am Fassberg 11
> 37077 Goettingen
>
> Telefon: 	+49 551 201-1882
> E-Mail: 	lfinsto at gwdg.de
>
>
>
> diff --git a/lib/Makefile.am b/lib/Makefile.am
> index 13531d9..dc6ada3 100644
> --- a/lib/Makefile.am
> +++ b/lib/Makefile.am
> @@ -23,7 +23,7 @@
>
>  ACLOCAL_AMFLAGS = -I m4 -I gl/m4
>
> -SUBDIRS = gl po includes x509
> +SUBDIRS = gl includes x509 #po
>  if ENABLE_MINITASN1
>  SUBDIRS += minitasn1
>  endif
> diff --git a/lib/build-aux/config.rpath b/lib/build-aux/config.rpath
> index c547c68..17298f2 100755
> --- a/lib/build-aux/config.rpath
> +++ b/lib/build-aux/config.rpath
> @@ -2,7 +2,7 @@
>  # Output a system dependent set of variables, describing how to set the
>  # run time search path of shared libraries in an executable.
>  #
> -#   Copyright 1996-2007 Free Software Foundation, Inc.
> +#   Copyright 1996-2010 Free Software Foundation, Inc.
>  #   Taken from GNU libtool, 2001
>  #   Originally by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996
>  #
> @@ -47,7 +47,7 @@ for cc_temp in $CC""; do
>  done
>  cc_basename=`echo "$cc_temp" | sed -e 's%^.*/%%'`
>
> -# Code taken from libtool.m4's AC_LIBTOOL_PROG_COMPILER_PIC.
> +# Code taken from libtool.m4's _LT_COMPILER_PIC.
>
>  wl=
>  if test "$GCC" = yes; then
> @@ -64,7 +64,7 @@ else
>            ;;
>        esac
>        ;;
> -    mingw* | cygwin* | pw32* | os2*)
> +    mingw* | cygwin* | pw32* | os2* | cegcc*)
>        ;;
>      hpux9* | hpux10* | hpux11*)
>        wl='-Wl,'
> @@ -76,7 +76,13 @@ else
>        ;;
>      linux* | k*bsd*-gnu)
>        case $cc_basename in
> -        icc* | ecc*)
> +        ecc*)
> +          wl='-Wl,'
> +          ;;
> +        icc* | ifort*)
> +          wl='-Wl,'
> +          ;;
> +        lf95*)
>            wl='-Wl,'
>            ;;
>          pgcc | pgf77 | pgf90)
> @@ -124,7 +130,7 @@ else
>    esac
>  fi
>
> -# Code taken from libtool.m4's AC_LIBTOOL_PROG_LD_SHLIBS.
> +# Code taken from libtool.m4's _LT_LINKER_SHLIBS.
>
>  hardcode_libdir_flag_spec=
>  hardcode_libdir_separator=
> @@ -132,7 +138,7 @@ hardcode_direct=no
>  hardcode_minus_L=no
>
>  case "$host_os" in
> -  cygwin* | mingw* | pw32*)
> +  cygwin* | mingw* | pw32* | cegcc*)
>      # FIXME: the MSVC++ port hasn't been tested in a loooong time
>      # When not using gcc, we currently assume that we are using
>      # Microsoft Visual C++.
> @@ -158,7 +164,7 @@ if test "$with_gnu_ld" = yes; then
>    # option of GNU ld is called -rpath, not --rpath.
>    hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
>    case "$host_os" in
> -    aix3* | aix4* | aix5*)
> +    aix[3-9]*)
>        # On AIX/PPC, the GNU linker is very broken
>        if test "$host_cpu" != ia64; then
>          ld_shlibs=no
> @@ -182,7 +188,7 @@ if test "$with_gnu_ld" = yes; then
>          ld_shlibs=no
>        fi
>        ;;
> -    cygwin* | mingw* | pw32*)
> +    cygwin* | mingw* | pw32* | cegcc*)
>        # hardcode_libdir_flag_spec is actually meaningless, as there is
>        # no search path for DLLs.
>        hardcode_libdir_flag_spec='-L$libdir'
> @@ -254,7 +260,7 @@ else
>          hardcode_direct=unsupported
>        fi
>        ;;
> -    aix4* | aix5*)
> +    aix[4-9]*)
>        if test "$host_cpu" = ia64; then
>          # On IA64, the linker does run time linking by default, so we
> don't
>          # have to do anything special.
> @@ -264,7 +270,7 @@ else
>          # Test if we are trying to use run time linking or normal
>          # AIX style linking. If -brtl is somewhere in LDFLAGS, we
>          # need to do runtime linking.
> -        case $host_os in aix4.[23]|aix4.[23].*|aix5*)
> +        case $host_os in aix4.[23]|aix4.[23].*|aix[5-9]*)
>            for ld_flag in $LDFLAGS; do
>              if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl");
> then
>                aix_use_runtimelinking=yes
> @@ -326,7 +332,7 @@ else
>        ;;
>      bsdi[45]*)
>        ;;
> -    cygwin* | mingw* | pw32*)
> +    cygwin* | mingw* | pw32* | cegcc*)
>        # When not using gcc, we currently assume that we are using
>        # Microsoft Visual C++.
>        # hardcode_libdir_flag_spec is actually meaningless, as there is
> @@ -494,7 +500,7 @@ else
>  fi
>
>  # Check dynamic linker characteristics
> -# Code taken from libtool.m4's AC_LIBTOOL_SYS_DYNAMIC_LINKER.
> +# Code taken from libtool.m4's _LT_SYS_DYNAMIC_LINKER.
>  # Unlike libtool.m4, here we don't care about _all_ names of the library,
> but
>  # only about the one the linker finds when passed -lNAME. This is the
> last
>  # element of library_names_spec in libtool.m4, or possibly two of them if
> the
> @@ -505,7 +511,7 @@ case "$host_os" in
>    aix3*)
>      library_names_spec='$libname.a'
>      ;;
> -  aix4* | aix5*)
> +  aix[4-9]*)
>      library_names_spec='$libname$shrext'
>      ;;
>    amigaos*)
> @@ -517,7 +523,7 @@ case "$host_os" in
>    bsdi[45]*)
>      library_names_spec='$libname$shrext'
>      ;;
> -  cygwin* | mingw* | pw32*)
> +  cygwin* | mingw* | pw32* | cegcc*)
>      shrext=.dll
>      library_names_spec='$libname.dll.a $libname.lib'
>      ;;
> diff --git a/lib/configure.ac b/lib/configure.ac
> index 80dd99e..2fa2bc4 100644
> --- a/lib/configure.ac
> +++ b/lib/configure.ac
> @@ -38,8 +38,8 @@ AC_PROG_LIBTOOL
>
>  LIBGNUTLS_HOOKS
>
> -AM_GNU_GETTEXT([external])
> -AM_GNU_GETTEXT_VERSION([0.17])
> +#AM_GNU_GETTEXT([external])
> +#AM_GNU_GETTEXT_VERSION([0.17])
>
>  AC_C_BIGENDIAN
>
> diff --git a/lib/m4/hooks.m4 b/lib/m4/hooks.m4
> index 86d7869..ada9d1d 100644
> --- a/lib/m4/hooks.m4
> +++ b/lib/m4/hooks.m4
> @@ -304,7 +304,7 @@ AC_DEFUN([LIBGNUTLS_HOOKS],
>
>    # For storing integers in pointers without warnings
>    #
> http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html#desc
> -  AC_CHECK_SIZEOF(void *)
> +  #AC_CHECK_SIZEOF(void *)
>    AC_CHECK_SIZEOF(long)
>    AC_CHECK_SIZEOF(int)
>    case $ac_cv_sizeof_void_p in
>
>
>


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From simon at josefsson.org  Thu Jul 29 16:07:43 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Jul 2010 16:07:43 +0200
Subject: master branch --- build problems
In-Reply-To: <69cac3d9eae49b7bda388c6904114e85.squirrel@mailbox.gwdg.de>
	(lfinsto@gwdg.de's message of "Thu, 29 Jul 2010 15:36:08 +0200")
References: <69cac3d9eae49b7bda388c6904114e85.squirrel@mailbox.gwdg.de>
Message-ID: <8762zyqt3k.fsf@mocca.josefsson.org>

lfinsto at gwdg.de writes:

> Hello,
>
> After installing the most recent stable releases of autoconf, automake and
> libtool:
>
> autoconf (GNU Autoconf) 2.66
> automake (GNU automake) 1.11.1
> libtool (GNU libtool) 2.2.10
>
> I had considerable difficulty getting the master branch to build, but I
> finally succeeded, though I had to comment some things out, which isn't so
> good.

This is strange, I have bootstrapped GnuTLS on completely freshly
installed Debian and Ubuntu systems without problems.  Instead of
looking at patches to solve some intermediate problem, can you quote the
complete output you get by doing the steps describe by README-alpha on
your machine?  I.e:

$ # install all dependencies according to README-alpha
$ git clone git://git.savannah.gnu.org/gnutls.git
$ cd gnutls
$ make
$ make

> In /lib/Makefile.am, I had to remove `po' from SUBDIRS.  The error that I
> got when it was included was this:
>
> config.status: error: cannot find input file: `po/Makefile.in.in'
> configure: error: ./configure failed for lib

It's generated by the bootstrap process.  There must have been an
earlier problem.  Most of your problems also seems to be a consequence
of broken bootstrapping.

> There a quite a few warnings like this:
>
> gaa.skel:593: warning: call to 'fseek' declared with attribute warning:
> fseek cannot handle files larger than 4 GB on 32-bit platforms - use
> fseeko function for handling of large files
>
> I suspect that they're not important, unless the files can be huge for
> some reason.

Yep, it is just a warning.  Would be nice to fix, but isn't critical,
and isn't related to your build problems.

> Lots of warnings like this one:
>
> serv.c:1163: warning: cast to pointer from integer of different size
>
> It would probably be worthwhile going through and trying to get rid of
> them.

Yep.  Before working on fixing warnings, I suggest using the most recent
GCC version to make sure you aren't fixing broken compiler warnings.

> Would you possibly consider checking `configure', the `Makefile.in' files,
> the contents of the `build-aux' directories and other generated files into
> the repository?  That way one (with a bit of luck) could at least get the
> version in the master branch to build without having to jump through too
> many hoops.

No, I don't want any generated files in git.  It causes a lot of
problems for people with different auto* tool versions.  More severe
problems than what you are seeing now, actually.

> I would also be interested to know what versions of autoconf, automake and
> libtool you have installed on the systems you're using.  I assume
> everything works together smoothly  on your systems.

I have autoconf 2.65, automake 1.11.1, and libtool 2.2.6b.  Straight
from Debian testing.

> One problem I ran into was these macro invocations in the top-level
> configure.ac:
>
> AC_LIBTOOL_WIN32_DLL
> AC_PROG_LIBTOOL
>
> This is from the libtool manual (for version 2.2.10):
>
>  -- Macro: LT_INIT (OPTIONS)
>  -- Macro: AC_PROG_LIBTOOL
>  -- Macro: AM_PROG_LIBTOOL
>      Add support for the `--enable-shared' and `--disable-shared'
>      `configure' flags.(1)  `AC_PROG_LIBTOOL' and `AM_PROG_LIBTOOL' are
>      deprecated names for older versions of this macro; `autoupdate'
>      will upgrade your `configure.ac' files.

Yeah, but it should still work, and we use the old names for
compatibility with older Libtool versions.  But maybe we should drop
that...

> Before I installed libtool 2.2.10, I got an error because of
> AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL.  I didn't get an error when I
> called LT_INIT, but the variable LIBTOOL wasn't defined and `configure'
> failed, unless it was `make' --- unfortunately, I didn't save this error.
>
> This, on the other hand, is from the Automake manual  (version 1.11.1, 8
> December 2009):
>
> `AC_PROG_LIBTOOL'
>      Automake will turn on processing for `libtool' (*note
>      Introduction: (libtool)Top.).
>
> LT_INIT isn't documented in this manual.  So, it would seem that Autoconf,
> Automake, and Libtool, or at least their most recent stable versions, are
> not perfectly synchronized with respect to these macros and it was rather
> frustrating trying to get `configure' and `make' to run, until it finally
> occurred to me to install a newer version of libtool.  However, since
> AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL are deprecated, I think it would
> be better to use LT_INIT instead.  I've made a note to myself to try this,
> now that I've got the package to build.

Changing that doesn't result in any code difference with modern tools,
it just means older Libtool won't work with GnuTLS.  In Libidn I have
this comment:

# We can't replace this with LT_INIT([win32-dll]) yet.  For example,
# the Ubuntu 8.04 LTS is still shipping a libtool version that doesn't
# have it.
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL

I'm not sure GnuTLS trunk really bootstraps on Ubuntu 8.04 LTS any more
though...

/Simon



From lfinsto at gwdg.de  Thu Jul 29 16:45:48 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Thu, 29 Jul 2010 16:45:48 +0200
Subject: master branch --- build problems
Message-ID: <b34f41edf65674b29c0548d7e6175b98.squirrel@mailbox.gwdg.de>

On Thu, July 29, 2010 4:07 pm, Simon Josefsson wrote:
> lfinsto at gwdg.de writes:

>> I had considerable difficulty getting the master branch to build, but I
finally succeeded, though I had to comment some things out, which isn't
so
>> good.
> This is strange, I have bootstrapped GnuTLS on completely freshly
installed Debian and Ubuntu systems without problems.

I'm not actually very satisfied with OpenSuse and I dislike Suse
Enterprise Edition, but I have to use them.  It doesn't surprise me that
I'm having problems.

> Instead of looking at patches to solve some intermediate problem, can
you quote the complete output you get by doing the steps describe by
README-alpha on your machine?  I.e:
> $ # install all dependencies according to README-alpha
> $ git clone git://git.savannah.gnu.org/gnutls.git
> $ cd gnutls
> $ make
> $ make

git clone git://git.savannah.gnu.org/gnutls.git master_test

[...]

lfinsto at pcfinston:~/gnutls_dev/master_test> make bootstrap

for f in lib/po/*.po.in; do \
		cp $f `echo $f | sed 's/.in//'`; \
	done

mv lib/build-aux/config.rpath lib/build-aux/config.rpath-
test -f ./configure || autoreconf --install
configure.ac:66: error: AC_CHECK_SIZEOF: requires literal arguments
../../lib/autoconf/types.m4:765: AC_CHECK_SIZEOF is expanded from...
lib/m4/hooks.m4:23: LIBGNUTLS_HOOKS is expanded from...
configure.ac:66: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: /usr/bin/autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1
make: *** [autoreconf] Error 1
lfinsto at pcfinston:~/gnutls_dev/master_test>

Commented-out AC_CHECK_SIZEOF(void *) in
~/gnutls_dev/master_test/lib/m4/hooks.m4

lfinsto at pcfinston:~/gnutls_dev/master_test> make bootstrap

for f in lib/po/*.po.in; do \
		cp $f `echo $f | sed 's/.in//'`; \
	done
mv lib/build-aux/config.rpath lib/build-aux/config.rpath-
mv: cannot stat `lib/build-aux/config.rpath': No such file or directory
make: *** [autoreconf] Error 1

lfinsto at pcfinston:~/gnutls_dev/master_test> autoreconf
gl/m4/intl.m4:242: warning: macro `AM_ICONV' not found in library
configure.ac:34: required file `build-aux/config.guess' not found
configure.ac:34:   `automake --add-missing' can install `config.guess'
configure.ac:39: required file `build-aux/config.rpath' not found
configure.ac:34: required file `build-aux/config.sub' not found
configure.ac:34:   `automake --add-missing' can install `config.sub'
configure.ac:29: required file `build-aux/install-sh' not found
configure.ac:29:   `automake --add-missing' can install `install-sh'
configure.ac:37: required file `build-aux/ltmain.sh' not found
configure.ac:29: required file `build-aux/missing' not found
configure.ac:29:   `automake --add-missing' can install `missing'
gcrypt/Makefile.am: required file `build-aux/depcomp' not found
gcrypt/Makefile.am:   `automake --add-missing' can install `depcomp'
Makefile.am: required file `./INSTALL' not found
Makefile.am:   `automake --add-missing' can install `INSTALL'
configure.ac:41: required file `./ABOUT-NLS' not found
autoreconf: automake failed with exit status: 1
lfinsto at pcfinston:~/gnutls_dev/master_test>

I didn't remember, but this is why I switched to `libtoolize', `aclocal',
etc.


>> In /lib/Makefile.am, I had to remove `po' from SUBDIRS.  The error that I
>> got when it was included was this:
>> config.status: error: cannot find input file: `po/Makefile.in.in'
configure: error: ./configure failed for lib
> It's generated by the bootstrap process.  There must have been an
earlier problem.  Most of your problems also seems to be a consequence
of broken bootstrapping.


> Yep.  Before working on fixing warnings, I suggest using the most recent
> GCC version to make sure you aren't fixing broken compiler warnings.

I'm using gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291].

I've read that installing glibc is somewhat of a challenge, but I suppose
I could try to install the current stable of release (or releases?) of
glibc and GCC in a non-standard location.

>> I would also be interested to know what versions of autoconf, automake and
>> libtool you have installed on the systems you're using.  I assume
everything works together smoothly  on your systems.

> I have autoconf 2.65, automake 1.11.1, and libtool 2.2.6b.  Straight
from > Debian testing.

So, nothing obviously old.

Laurence


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de







From simon at josefsson.org  Thu Jul 29 19:35:04 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Jul 2010 19:35:04 +0200
Subject: master branch --- build problems
In-Reply-To: <b34f41edf65674b29c0548d7e6175b98.squirrel@mailbox.gwdg.de>
	(lfinsto@gwdg.de's message of "Thu, 29 Jul 2010 16:45:48 +0200")
References: <b34f41edf65674b29c0548d7e6175b98.squirrel@mailbox.gwdg.de>
Message-ID: <87aapanqd3.fsf@mocca.josefsson.org>

lfinsto at gwdg.de writes:

> On Thu, July 29, 2010 4:07 pm, Simon Josefsson wrote:
>> lfinsto at gwdg.de writes:
>
>>> I had considerable difficulty getting the master branch to build, but I
> finally succeeded, though I had to comment some things out, which isn't
> so
>>> good.
>> This is strange, I have bootstrapped GnuTLS on completely freshly
> installed Debian and Ubuntu systems without problems.
>
> I'm not actually very satisfied with OpenSuse and I dislike Suse
> Enterprise Edition, but I have to use them.  It doesn't surprise me that
> I'm having problems.

Perhaps few people have used this system for bootstrapping.

>> Instead of looking at patches to solve some intermediate problem, can
> you quote the complete output you get by doing the steps describe by
> README-alpha on your machine?  I.e:
>> $ # install all dependencies according to README-alpha
>> $ git clone git://git.savannah.gnu.org/gnutls.git
>> $ cd gnutls
>> $ make
>> $ make
>
> git clone git://git.savannah.gnu.org/gnutls.git master_test
>
> [...]
>
> lfinsto at pcfinston:~/gnutls_dev/master_test> make bootstrap
>
> for f in lib/po/*.po.in; do \
> 		cp $f `echo $f | sed 's/.in//'`; \
> 	done
>
> mv lib/build-aux/config.rpath lib/build-aux/config.rpath-
> test -f ./configure || autoreconf --install
> configure.ac:66: error: AC_CHECK_SIZEOF: requires literal arguments
> ../../lib/autoconf/types.m4:765: AC_CHECK_SIZEOF is expanded from...
> lib/m4/hooks.m4:23: LIBGNUTLS_HOOKS is expanded from...
> configure.ac:66: the top level

That's the problem we should focus on.  Does it help to change:

  AC_CHECK_SIZEOF(void *)
  AC_CHECK_SIZEOF(long)
  AC_CHECK_SIZEOF(int)

into

  AC_CHECK_SIZEOF([void *])
  AC_CHECK_SIZEOF([long])
  AC_CHECK_SIZEOF([int])

?  Don't forget to clean the directory before re-attempting the
bootstrap.

I wonder why I don't get the same error, but I use autoconf 2.65 and not
2.66.

> Commented-out AC_CHECK_SIZEOF(void *) in
> ~/gnutls_dev/master_test/lib/m4/hooks.m4
>
> lfinsto at pcfinston:~/gnutls_dev/master_test> make bootstrap
>
> for f in lib/po/*.po.in; do \
> 		cp $f `echo $f | sed 's/.in//'`; \
> 	done
> mv lib/build-aux/config.rpath lib/build-aux/config.rpath-
> mv: cannot stat `lib/build-aux/config.rpath': No such file or directory
> make: *** [autoreconf] Error 1

You can't do this, you need to clean out the directory after a hard
failure like the first one.  It moves files around.

>> Yep.  Before working on fixing warnings, I suggest using the most recent
>> GCC version to make sure you aren't fixing broken compiler warnings.
>
> I'm using gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291].
>
> I've read that installing glibc is somewhat of a challenge, but I suppose
> I could try to install the current stable of release (or releases?) of
> glibc and GCC in a non-standard location.

You don't need to upgrade glibc at all.  And upgrading gcc is only if
you want to work on fixing these warnings.  I suggest you wait with this
until you have a stable development environment.

>>> I would also be interested to know what versions of autoconf, automake and
>>> libtool you have installed on the systems you're using.  I assume
> everything works together smoothly  on your systems.
>
>> I have autoconf 2.65, automake 1.11.1, and libtool 2.2.6b.  Straight
> from > Debian testing.
>
> So, nothing obviously old.

Could be that autoconf 2.66 has somewhat tighter syntax checks though.

/Simon



From lfinsto at gwdg.de  Fri Jul 30 09:51:59 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 30 Jul 2010 09:51:59 +0200
Subject: master branch --- build problems
Message-ID: <909753d2b8f354ee101f273d94eb900a.squirrel@mailbox.gwdg.de>

On Thu, July 29, 2010 7:35 pm, Simon Josefsson wrote:
> lfinsto at gwdg.de writes:
>> On Thu, July 29, 2010 4:07 pm, Simon Josefsson wrote:
>>> lfinsto at gwdg.de writes:

>> I'm not actually very satisfied with OpenSuse and I dislike Suse
Enterprise Edition, but I have to use them.  It doesn't surprise me that
>> I'm having problems.
> Perhaps few people have used this system for bootstrapping.

I could be wrong, of course, but I doubt that anyone has, since I would
expect them to have the same problems.  The version of GNUTLS I got with
the Package Manager is 2.4.1-24.4.1 (x86_64) openSUSE 11.1-Update, and I
just checked that 2.4.1 is from June 2008.  However, it works and it works
together with the other outdated versions of packages you get this way.

Since OpenSUSE is fairly widespread, I think it's worthwhile to try to get
this to work.

>> mv lib/build-aux/config.rpath lib/build-aux/config.rpath-
>> test -f ./configure || autoreconf --install
>> configure.ac:66: error: AC_CHECK_SIZEOF: requires literal arguments
../../lib/autoconf/types.m4:765: AC_CHECK_SIZEOF is expanded from...
lib/m4/hooks.m4:23: LIBGNUTLS_HOOKS is expanded from...
>> configure.ac:66: the top level
> That's the problem we should focus on.  Does it help to change:
>   AC_CHECK_SIZEOF(void *)
>   AC_CHECK_SIZEOF(long)
>   AC_CHECK_SIZEOF(int)
> into
>   AC_CHECK_SIZEOF([void *])
>   AC_CHECK_SIZEOF([long])
>   AC_CHECK_SIZEOF([int])

No.  "long" and "int" don't need to be quoted and quoting "void*" doesn't
work.  However, the manual indicates that it should.  I don't whether a)
the behaviour is correct and the manual hasn't been updated or b) it's a
bug in Autoconf.  I'll look through the Autoconf mailing list archives to
see if this has been discussed and if not, I'll ask about it.

> ?  Don't forget to clean the directory before re-attempting the
> bootstrap.

I don't know whether `make clean' works at this point, but I'll try. 
Otherwise, I can just revert my working copy of the repository.

> You don't need to upgrade glibc at all.  And upgrading gcc is only if
> you want to work on fixing these warnings.  I suggest you wait with this
> until you have a stable development environment.

Again, I could be wrong, but I think the most likely explanation is that
the program assumes at these places that pointers and integers are the
same size, which is not true on my system.  This is usually not difficult
to fix, but I found myself tracing back through declarations of data
types.

I don't think these warnings are that important and it would be more
important to document the data types, which is one of things I wanted to
do in the first place.  If I'm right, getting rid of these warnings is
probably just a matter of adding casts appropriately and/or changing a few
declarations, but I don't want to change anything without understanding
what's going on.

Laurence

-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de









From lfinsto at gwdg.de  Fri Jul 30 10:12:52 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 30 Jul 2010 10:12:52 +0200
Subject: master branch --- build problems
In-Reply-To: <909753d2b8f354ee101f273d94eb900a.squirrel@mailbox.gwdg.de>
References: <909753d2b8f354ee101f273d94eb900a.squirrel@mailbox.gwdg.de>
Message-ID: <e585d7a8e6898797f7389fde7345f58f.squirrel@mailbox.gwdg.de>


On Fri, July 30, 2010 9:51 am, lfinsto at gwdg.de wrote:

> No.  "long" and "int" don't need to be quoted and quoting "void*" doesn't
> work.  However, the manual indicates that it should.  I don't whether a)
> the behaviour is correct and the manual hasn't been updated or b) it's a
> bug in Autoconf.  I'll look through the Autoconf mailing list archives to
> see if this has been discussed and if not, I'll ask about it.

It's a bug in Autoconf 2.66.  There's a discussion with the title
"AC_CHECK_SIZEOF([int *]) is error in autoconf-2.66" on autoconf at gnu.org.

http://lists.gnu.org/archive/html/autoconf/2010-07/threads.html#00005

There's a patch that fixes the problem.  Autoconf 2.67 is available in the
git repository, but not yet on the GNU ftp server.

Laurence

-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From lfinsto at gwdg.de  Fri Jul 30 11:39:54 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 30 Jul 2010 11:39:54 +0200
Subject: master branch --- build problems
In-Reply-To: <e585d7a8e6898797f7389fde7345f58f.squirrel@mailbox.gwdg.de>
References: <909753d2b8f354ee101f273d94eb900a.squirrel@mailbox.gwdg.de>
	<e585d7a8e6898797f7389fde7345f58f.squirrel@mailbox.gwdg.de>
Message-ID: <2ff6947a7fcd4d99174e3c160f72e2e1.squirrel@mailbox.gwdg.de>


On Fri, July 30, 2010 10:12 am, lfinsto at gwdg.de wrote:

I've installed autoconf (GNU Autoconf) 2.67.4-14f35, i.e., the current
HEAD of the Autoconf git repository at Savannah.

The following sequence of commands works with no new problems or errors. 
These are the remaining problems:

1. LDFLAGS must be set explicitly or libgcrypt isn't found.

2.  configure must be called after `make bootstrap' because the latter
doesn't accept options.

3.  Files installed by libtoolize are not readable by the user (?!).

4.  gcrypt.h isn't found "automatically".

In my opinion, the current state of things on my system is acceptable,
although it's a bit boring watching the configure scripts run repeatedly.
I think it would be nice to make it easier for people who don't
necessarily know how to go through the various steps, but I can't think of
any obvious way of doing this.

Laurence

********************************************************************

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> export
LDFLAGS="-L/home/lfinsto/libgcrypt-1.4.6/lib"

lfinsto at pcfinston:~/gnutls_dev> git clone
lfinsto1 at git.sv.gnu.org:/srv/git/gnutls.git gnutls_master
Cloning into gnutls_master...

[...]

lfinsto at pcfinston:~/gnutls_dev> cd gnutls_master/
lfinsto at pcfinston:~/gnutls_dev/gnutls_master> make bootstrap
for f in lib/po/*.po.in; do \
		cp $f `echo $f | sed 's/.in//'`; \
	done
mv lib/build-aux/config.rpath lib/build-aux/config.rpath-
test -f ./configure || autoreconf --install
Copying file ABOUT-NLS

[...]

configure: error: cannot run /bin/sh build-aux/config.sub
make: *** [bootstrap] Error 126

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> chmod u+r build-aux/*

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> make bootstrap

[...]

configure: error: cannot run /bin/sh build-aux/config.sub
configure: error: ./configure failed for lib
make: *** [bootstrap] Error 126

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> chmod u+r lib/build-aux/*
libextra/build-aux/*

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> make bootstrap

[...]

configure: summary of build options:

  version:          2.11.0 shared 43:0:17
  Host type:        x86_64-unknown-linux-gnu
  Install prefix:   /usr/local
  Compiler:         gcc -std=gnu99
  Warning flags:    errors:  -Werror warnings:  -Wall -W -Wformat-security
-Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas
-Wstrict-aliasing -Wfloat-equal -Wdeclaration-after-statement
-Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested-externs
-Winline -Winvalid-pch -Wlong-long -Wvolatile-register-var
-Wdisabled-optimization -Wstack-protector -Woverlength-strings
-Wattributes -Wcoverage-mismatch -Wmultichar -Wunused-macros
-Wno-missing-field-initializers -Wno-sign-compare -Wno-pointer-sign
-Wno-unused-parameter -Wno-unused-parameter -Wno-stack-protector
-Wno-int-to-pointer-cast -fdiagnostics-show-option
  Library types:    Shared=yes, Static=yes
  Valgrind:         yes valgrind -q
  Guile wrappers:   no
  C++ library:      yes
  OpenSSL library:  yes
  /dev/crypto:      no
  Crypto library:   libgcrypt

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> configure
--disable-valgrind-tests
--with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6 --prefix=`pwd`

[...]

configure: summary of build options:

  version:          2.11.0 shared 43:0:17
  Host type:        x86_64-unknown-linux-gnu
  Install prefix:   /home/lfinsto/gnutls_dev/gnutls_master
  Compiler:         gcc -std=gnu99
  Warning flags:    errors:  warnings:
  Library types:    Shared=yes, Static=yes
  Valgrind:         no
  Guile wrappers:   no
  C++ library:      yes
  OpenSSL library:  yes
  /dev/crypto:      no
  Crypto library:   libgcrypt

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> make

[...]

  CC     init.lo
init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a
function)
make[4]: *** [init.lo] Error 1
make[4]: Leaving directory
`/home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master'
make: *** [all] Error 2

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> ln -s
/home/lfinsto/libgcrypt-1.4.6/include/gcrypt.h
/home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt/gcrypt.h

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> make

Succeeded.

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> make check

Succeeded.

Making check in lib
make[1]: Entering directory `/home/lfinsto/gnutls_dev/gnutls_master/lib'
Making check in gl

lfinsto at pcfinston:~/gnutls_dev/gnutls_master> make install

Succeeded.




-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From simon at josefsson.org  Fri Jul 30 16:01:34 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 30 Jul 2010 16:01:34 +0200
Subject: master branch --- build problems
In-Reply-To: <2ff6947a7fcd4d99174e3c160f72e2e1.squirrel@mailbox.gwdg.de>
	(lfinsto@gwdg.de's message of "Fri, 30 Jul 2010 11:39:54 +0200")
References: <909753d2b8f354ee101f273d94eb900a.squirrel@mailbox.gwdg.de>
	<e585d7a8e6898797f7389fde7345f58f.squirrel@mailbox.gwdg.de>
	<2ff6947a7fcd4d99174e3c160f72e2e1.squirrel@mailbox.gwdg.de>
Message-ID: <87fwz13w75.fsf@mocca.josefsson.org>

lfinsto at gwdg.de writes:

> On Fri, July 30, 2010 10:12 am, lfinsto at gwdg.de wrote:
>
> I've installed autoconf (GNU Autoconf) 2.67.4-14f35, i.e., the current
> HEAD of the Autoconf git repository at Savannah.
>
> The following sequence of commands works with no new problems or errors. 
> These are the remaining problems:
>
> 1. LDFLAGS must be set explicitly or libgcrypt isn't found.

Try --with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6 instead.  In
my experience LDFLAGS can causes more problems than it solves.

> 2.  configure must be called after `make bootstrap' because the latter
> doesn't accept options.

It does, you may supply them as 'make ADDFLAGS=--with-foo' or similar.
Check at the top of cfg.mk for variable names and how they are used.

> 3.  Files installed by libtoolize are not readable by the user (?!).

This seems weird, and could be a problem with your libtool installation.
Maybe you can debug it?

> 4.  gcrypt.h isn't found "automatically".

It should be if you use --with-libgcrypt-prefix.

> In my opinion, the current state of things on my system is acceptable,
> although it's a bit boring watching the configure scripts run repeatedly.
> I think it would be nice to make it easier for people who don't
> necessarily know how to go through the various steps, but I can't think of
> any obvious way of doing this.

The README-alpha file should cover what is needed for typical
environments, and we could extend it with more things if needed.  I
think the main problem for you was the Autoconf 2.66 bug -- the above
problem appear solvable.

/Simon



From lfinsto at gwdg.de  Fri Jul 30 16:21:13 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 30 Jul 2010 16:21:13 +0200
Subject: master branch --- build problems
In-Reply-To: <87fwz13w75.fsf@mocca.josefsson.org>
References: <909753d2b8f354ee101f273d94eb900a.squirrel@mailbox.gwdg.de>
	<e585d7a8e6898797f7389fde7345f58f.squirrel@mailbox.gwdg.de>
	<2ff6947a7fcd4d99174e3c160f72e2e1.squirrel@mailbox.gwdg.de>
	<87fwz13w75.fsf@mocca.josefsson.org>
Message-ID: <1130a5387b787686d67649113caa3641.squirrel@mailbox.gwdg.de>


On Fri, July 30, 2010 4:01 pm, Simon Josefsson wrote:
> lfinsto at gwdg.de writes:
>
>> On Fri, July 30, 2010 10:12 am, lfinsto at gwdg.de wrote:

>>
>> 1. LDFLAGS must be set explicitly or libgcrypt isn't found.
>
> Try --with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6 instead.  In
> my experience LDFLAGS can causes more problems than it solves.

I always call configure with this option.  I was trying to find out why
libgcrypt wasn't always found.  I think I may have found the place where
things go wrong, but I have to trace back through some m4 macro
definitions.  I'll have to get back to this another time.

>
>> 2.  configure must be called after `make bootstrap' because the latter
>> doesn't accept options.
>
> It does, you may supply them as 'make ADDFLAGS=--with-foo' or similar.
> Check at the top of cfg.mk for variable names and how they are used.

Okay, thanks.

>
>> 3.  Files installed by libtoolize are not readable by the user (?!).
>
> This seems weird, and could be a problem with your libtool installation.
> Maybe you can debug it?

I'll try.

>
>> 4.  gcrypt.h isn't found "automatically".
>
> It should be if you use --with-libgcrypt-prefix.

This would seem to be more-or-less the same problem as above.  This is the
note I've made to myself:

Start in ~/gnutls_dev/gnutls_master/lib/m4/hooks.m4:  Trace what
AC_LIB_HAVE_LINKFLAGS does.  Try to get the path of the libgnutls library
and header files out and use them where needed.  See
~/gnutls_dev/gnutls_master/lib/gcrypt/Makefile.am.  I think AM_CPPFLAGS in
this file needs to be changed for this to work.

Laurence


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de




From lfinsto at gwdg.de  Fri Jul 30 16:24:55 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 30 Jul 2010 16:24:55 +0200
Subject: Example for /doc/examples/ using Flex and Bison
Message-ID: <b3bb876fc875ca8c671c50dfe308a802.squirrel@mailbox.gwdg.de>

Hello,

This may or not be of interest to you, but I thought I'd send it in case
it is.

The application I've written for my job uses a server and client that
communicate using two scanner/parser pairs, one for each peer.  They are
written using Flex and GNU Bison.  It is slightly tricky getting this to
work and the actual application is already fairly complicated, so I wanted
to make a simple example, while it's fresh in my mind.  I think it would
be most useful if it was included in the GNUTLS package, where people
would find it.

The attached file `a.txt' contains a patch for /doc/examples/.  I've
copied and modified ex-serv-anon.c and ex-client1.c.  The modified
versions are called ex-serv-anon-parse.c and ex-client1-parse.c.

The input files for GNU Bison are called prsrserv.y and prsrclnt.y,
respectively.

The input files for Flex are called scnrserv.y and scnrclnt.y,
respectively.

There's a header file called scanprse.h.

I've added rules to /doc/example/Makefile.am.

In addition, I've added a call to AM_PROG_LEX to the top-level
configure.ac file, but I haven't included this in the patch.

The client sends "Client finished" to the server and the server sends
"Server finished" to the client.  Then the client exits.  The idea is that
they can continue sending messages back and forth until they're both
finished and these messages will be processed by the respective
scanner/parser pair;  yylex/yyparse for the server and zzlex/zzparse for
the client.  That is, the server and the client can each have its own
"language".  The current state is not as polished as I would have liked,
but I don't have time to work on this anymore today and at least the
framework is present.

It's not entirely obvious what header files need to be included and in
what order, what options are needed for Bison, what needs to be called
"zz*" instead of "yy*", etc., especially for people who are new to Flex
and or Bison, so I think it would be a good idea to have a simple example
of this somewhere.

Please have a look if you feel like it and let me know if you think it
would be worthwhile to refine to a point where it could be included in the
package.

Laurence






-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a.txt
URL: </pipermail/attachments/20100730/fdb351f4/attachment.txt>

From lfinsto at gwdg.de  Fri Jul 30 16:36:21 2010
From: lfinsto at gwdg.de (lfinsto at gwdg.de)
Date: Fri, 30 Jul 2010 16:36:21 +0200
Subject: Example for /doc/examples/ using Flex and Bison
In-Reply-To: <b3bb876fc875ca8c671c50dfe308a802.squirrel@mailbox.gwdg.de>
References: <b3bb876fc875ca8c671c50dfe308a802.squirrel@mailbox.gwdg.de>
Message-ID: <68644c0c644617d8de9de6c078a9765a.squirrel@mailbox.gwdg.de>


On Fri, July 30, 2010 4:24 pm, lfinsto at gwdg.de wrote:

> The input files for GNU Bison are called prsrserv.y and prsrclnt.y,
> respectively.
>
> The input files for Flex are called scnrserv.y and scnrclnt.y,
> respectively.

No, they're not. They're called scnrserv.l and scnrclnt.l.

Laurence


-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen

Telefon: 	+49 551 201-1882
E-Mail: 	lfinsto at gwdg.de