From nmav at gnutls.org Thu Jul 1 15:21:58 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Thu, 1 Jul 2004 16:21:58 +0300 Subject: [gnutls-dev] building gnutls 1.0.14 with included opencdk In-Reply-To: <40E1E59A.70108@danger.com> References: <40E1E59A.70108@danger.com> Message-ID: <200407011621.58329.nmav@gnutls.org> On Wednesday 30 June 2004 00:56, Robey Pointer wrote: > When building gnutls 1.0.14 with the included opencdk library, openpgp > is unable to find the opencdk include file. > It looks like "libextra/opencdk" should be added to the include path in > this case, but I couldn't figure out a simple way to do that (I have > zero understanding of 'configure') so my temporary patch has been to > hand-edit this file: > libextra/openpgp/openpgp.h Could you send me the output of make? I need to know in which files this failed, since I cannot reproduce it. > Thanks! > robey -- Nikos Mavroyanopoulos From robey at danger.com Thu Jul 1 19:29:41 2004 From: robey at danger.com (Robey Pointer) Date: Thu, 01 Jul 2004 10:29:41 -0700 Subject: [gnutls-dev] building gnutls 1.0.14 with included opencdk In-Reply-To: <200407011621.58329.nmav@gnutls.org> References: <40E1E59A.70108@danger.com> <200407011621.58329.nmav@gnutls.org> Message-ID: <40E44A05.1040200@danger.com> Nikos Mavroyanopoulos wrote: >On Wednesday 30 June 2004 00:56, Robey Pointer wrote: > > >>When building gnutls 1.0.14 with the included opencdk library, openpgp >>is unable to find the opencdk include file. >>It looks like "libextra/opencdk" should be added to the include path in >>this case, but I couldn't figure out a simple way to do that (I have >>zero understanding of 'configure') so my temporary patch has been to >>hand-edit this file: >>libextra/openpgp/openpgp.h >> >> >Could you send me the output of make? I need to know in which files >this failed, since I cannot reproduce it. > > Here you go. :) gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../ -I../../includes/ -I../../lib/minitasn1 -I/danger/local/include -I/danger/local/include -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -pipe -I/danger/local/include -I/danger/local/include -MT verify.lo -MD -MP -MF .deps/verify.Tpo -c verify.c -fPIC -DPIC -o .libs/verify.o In file included from ../auth_cert.h:6, from ../gnutls_sig.h:3, from verify.c:33: ../../libextra/openpgp/openpgp.h:15: error: parse error before "cdk_kbnode_t" ../../libextra/openpgp/openpgp.h:15: warning: no semicolon at end of struct or union ../../libextra/openpgp/openpgp.h:16: warning: data definition has no type or storage class ../../libextra/openpgp/openpgp.h:17: warning: data definition has no type or storage class ../../libextra/openpgp/openpgp.h:24: error: parse error before "cdk_keydb_hd_t" ../../libextra/openpgp/openpgp.h:24: warning: no semicolon at end of struct or union ../../libextra/openpgp/openpgp.h:25: warning: data definition has no type or storage class ../../libextra/openpgp/openpgp.h:28: error: parse error before "cdk_stream_t" ../../libextra/openpgp/openpgp.h:28: warning: no semicolon at end of struct or union ../../libextra/openpgp/openpgp.h:29: warning: data definition has no type or storage class make[4]: *** [verify.lo] Error 1 make[4]: Leaving directory `/home/robey/danger/service/third_party/gnutls-1.0.14/lib/x509' robey From nmav at gnutls.org Sat Jul 10 12:23:37 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat, 10 Jul 2004 13:23:37 +0300 Subject: [gnutls-dev] gnutls 1.0.16 Message-ID: <200407101323.37136.nmav@gnutls.org> I've released gnutls 1.0.16. The changes since the last release are: - Do not free the SRP (prime and generator) parameters obtained from the callback if they are the static ones defined in extra.h. - Eliminated some memory leaks. Reported by Yoann Vandoorselaere. - Some fixes in the makefiles. -- Nikos Mavroyanopoulos From bfriesen at simple.dallas.tx.us Thu Jul 22 03:07:19 2004 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Wed, 21 Jul 2004 20:07:19 -0500 (CDT) Subject: [gnutls-dev] Problem linking gnutls 1.0.16 Message-ID: I am building gnutls and friends on a Solaris 9 system with gcc 3.4.1, using the Solaris linker. The whole process has been quite painful. In some places I had to edit Makefile.am files and add missing library dependencies. It seems that perhaps gnutls relies on some automatic library dependency support provided by the OS. I have installed libgpg-error-0.7, libgcrypt-1.2.0, libtasn1-0.2.10, and opencdk-0.5.5. I am now down to the final link stage but am stuck at the following error. Can someone please help? gmake[3]: Entering directory `/home/bfriesen/src/im/gnutls-1.0.16/src' /bin/sh ../libtool --mode=link gcc-3.4.1 -O2 -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -I/usr/local/include -I/usr/local/include -L/usr/local/lib -R/usr/local/lib -o gnutls-serv serv-gaa.o serv.o common.o ../lib/libgnutls.la ../libextra/libgnutls-extra.la -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error -lz -lnsl -lsocket -L/usr/local/lib -lopencdk -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error -L/usr/local/lib -ltasn1 -lz -lz gcc-3.4.1 -O2 -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -I/usr/local/include -I/usr/local/include -o .libs/gnutls-serv serv-gaa.o serv.o common.o -L/usr/local/lib ../lib/.libs/libgnutls ../libextra/.libs/libgnutls-extra /home/bfriesen/src/im/gnutls-1.0.16/lib/.libs/libgnutls /usr/local/lib/libopencdk.so /usr/local/lib/libgcrypt -lnsl -lsocket /usr/local/lib/libgpg-error.so /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -lc /usr/local/lib/libtasn1.so -lz -R/usr/local/lib ld: warning: file /home/bfriesen/src/im/gnutls-1.0.16/lib/.libs/libgnutls: linked to ../lib/.libs/libgnutls: attempted multiple inclusion of file Undefined first referenced symbol in file gnutls_x509_crt_check_hostname common.o gnutls_openpgp_key_to_xml common.o _gnutls_hostname_compare ../libextra/.libs/libgnutls-extra gnutls_x509_crt_to_xml common.o ld: fatal: Symbol referencing errors. No output written to .libs/gnutls-serv collect2: ld returned 1 exit status gmake[3]: *** [gnutls-serv] Error 1 gmake[3]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16' gmake: *** [all] Error 2 ====================================== Bob Friesenhahn bfriesen at simple.dallas.tx.us http://www.simplesystems.org/users/bfriesen From smurf at smurf.noris.de Fri Jul 23 10:30:22 2004 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Fri, 23 Jul 2004 10:30:22 +0200 Subject: [gnutls-dev] libtasn1 0.2.10 not in CVS ? Message-ID: <20040723083018.GS6949@kiste> Hello, I noticed that libtasn1 0.2.10 is to be found at ftp://ftp.gnutls.org/pub/gnutls/libtasn1/, but the CVS repository ends with 0.2.9. Please fix. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nmav at gnutls.org Sat Jul 24 19:57:05 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat, 24 Jul 2004 20:57:05 +0300 Subject: [gnutls-dev] libtasn1 0.2.10 not in CVS ? In-Reply-To: <20040723083018.GS6949@kiste> References: <20040723083018.GS6949@kiste> Message-ID: <200407242057.05495.nmav@gnutls.org> On Friday 23 July 2004 11:30, Matthias Urlichs wrote: > Hello, > I noticed that libtasn1 0.2.10 is to be found at > ftp://ftp.gnutls.org/pub/gnutls/libtasn1/, but the CVS repository ends > with 0.2.9. > Please fix. This is not true. I just checked the web cvs repository and seems fine to me. -- Nikos Mavroyanopoulos From nmav at gnutls.org Sat Jul 24 20:03:38 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sat, 24 Jul 2004 21:03:38 +0300 Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: References: Message-ID: <200407242103.38206.nmav@gnutls.org> On Thursday 22 July 2004 04:07, Bob Friesenhahn wrote: > I am building gnutls and friends on a Solaris 9 system with gcc 3.4.1, > > The whole process has been quite painful. In some places I had to > edit Makefile.am files and add missing library dependencies. It seems > that perhaps gnutls relies on some automatic library dependency > support provided by the OS. I have installed libgpg-error-0.7, > libgcrypt-1.2.0, libtasn1-0.2.10, and opencdk-0.5.5. > I am now down to the final link stage but am stuck at the following > error. Can someone please help? Could you send me the line that the final linking of libgnutls.so is done? It seems that some objects (such as lib/x509/rfc2818_hostname) do not get included. Have you used any configure options? > > /home/bfriesen/src/im/gnutls-1.0.16/lib/.libs/libgnutls: linked to > ../lib/.libs/libgnutls: attempted multiple inclusion of file It seems however that the library is created. Could you check the library (with nm) for the following symbols? Does the linking of other programs work? > Undefined first referenced > symbol in file > gnutls_x509_crt_check_hostname common.o > gnutls_openpgp_key_to_xml common.o > _gnutls_hostname_compare ../libextra/.libs/libgnutls-extra > gnutls_x509_crt_to_xml common.o > ld: fatal: Symbol referencing errors. No output written to > .libs/gnutls-serv > collect2: ld returned 1 exit status > gmake[3]: *** [gnutls-serv] Error 1 > gmake[3]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16/src' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16/src' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16' > gmake: *** [all] Error 2 > > > ====================================== > Bob Friesenhahn > bfriesen at simple.dallas.tx.us > http://www.simplesystems.org/users/bfriesen > > _______________________________________________ > Gnutls-dev mailing list > Gnutls-dev at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnutls-dev -- Nikos Mavroyanopoulos From bfriesen at simple.dallas.tx.us Sat Jul 24 22:38:25 2004 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sat, 24 Jul 2004 15:38:25 -0500 (CDT) Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: <200407242103.38206.nmav@gnutls.org> References: <200407242103.38206.nmav@gnutls.org> Message-ID: On Sat, 24 Jul 2004, Nikos Mavroyanopoulos wrote: > On Thursday 22 July 2004 04:07, Bob Friesenhahn wrote: > >> I am building gnutls and friends on a Solaris 9 system with gcc 3.4.1, >> >> The whole process has been quite painful. In some places I had to >> edit Makefile.am files and add missing library dependencies. It seems >> that perhaps gnutls relies on some automatic library dependency >> support provided by the OS. I have installed libgpg-error-0.7, >> libgcrypt-1.2.0, libtasn1-0.2.10, and opencdk-0.5.5. >> I am now down to the final link stage but am stuck at the following >> error. Can someone please help? > Could you send me the line that the final linking of libgnutls.so > is done? It seems that some objects (such as lib/x509/rfc2818_hostname) > do not get included. Have you used any configure options? /bin/sh ../libtool --mode=link gcc-3.4.1 -O2 -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -I/usr/local/include -I/usr/local/include -L/usr/local/lib -R/usr/local/lib -o gnutls-serv serv-gaa.o serv.o common.o ../lib/libgnutls.la ../libextra/libgnutls-extra.la -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error -lz -lnsl -lsocket -L/usr/local/lib -lopencdk -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error -L/usr/local/lib -ltasn1 -lz -lz gcc-3.4.1 -O2 -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -I/usr/local/include -I/usr/local/include -o .libs/gnutls-serv serv-gaa.o serv.o common.o -L/usr/local/lib ../lib/.libs/libgnutls ../libextra/.libs/libgnutls-extra /home/bfriesen/src/im/gnutls-1.0.16/lib/.libs/libgnutls /usr/local/lib/libopencdk.so /usr/local/lib/libgcrypt -lnsl -lsocket /usr/local/lib/libgpg-error.so /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -lc /usr/local/lib/libtasn1.so -lz -R/usr/local/lib ld: warning: file /home/bfriesen/src/im/gnutls-1.0.16/lib/.libs/libgnutls: linked to ../lib/.libs/libgnutls: attempted multiple inclusion of file Undefined first referenced symbol in file gnutls_x509_crt_check_hostname common.o gnutls_openpgp_key_to_xml common.o _gnutls_hostname_compare ../libextra/.libs/libgnutls-extra gnutls_x509_crt_to_xml common.o ld: fatal: Symbol referencing errors. No output written to .libs/gnutls-serv collect2: ld returned 1 exit status gmake[3]: *** [gnutls-serv] Error 1 gmake[3]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/bfriesen/src/im/gnutls-1.0.16' gmake: *** [all] Error 2 >> /home/bfriesen/src/im/gnutls-1.0.16/lib/.libs/libgnutls: linked to >> ../lib/.libs/libgnutls: attempted multiple inclusion of file > It seems however that the library is created. Could you check > the library (with nm) for the following symbols? Does the linking > of other programs work? Nm shows that lib/x509/.libs/libx509.a contains the symbols gnutls_x509_crt_check_hostname, _gnutls_hostname_compare, and gnutls_x509_crt_to_xml. If this library is used as a libtool convenience library, then it is likely the problem is due due to multiple occurances of common.o in the package: blade:src/im/gnutls-1.0.16% find . -name 'common.o' -print ./lib/x509/.libs/common.o ./lib/x509/common.o ./src/common.o Objects from libtool convenience libraries are extracted to individual .o files prior to use so it is likely that this is why the linker fails to see the symbols (two common.o files in the same library, oops!). I did have to update a number of Makefile.am files in packages gnutils depends on since the library dependencies were sometimes not completely listed. Apparently the Linux linker will silently insert library dependencies (recorded in the .so file), but this is not true of most platforms so it is necessary to tell libtool about all dependencies so they can be recorded in the .la file. Bob ====================================== Bob Friesenhahn bfriesen at simple.dallas.tx.us http://www.simplesystems.org/users/bfriesen From nmav at gnutls.org Sat Jul 24 23:14:38 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun, 25 Jul 2004 00:14:38 +0300 Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: References: <200407242103.38206.nmav@gnutls.org> Message-ID: <200407250014.38874.nmav@gnutls.org> On Saturday 24 July 2004 23:38, Bob Friesenhahn wrote: > >> /home/bfriesen/src/im/gnutls-1.0.16/lib/.libs/libgnutls: linked to > >> ../lib/.libs/libgnutls: attempted multiple inclusion of file > > It seems however that the library is created. Could you check > > the library (with nm) for the following symbols? Does the linking > > of other programs work? > Nm shows that lib/x509/.libs/libx509.a contains the symbols > gnutls_x509_crt_check_hostname, _gnutls_hostname_compare, and > gnutls_x509_crt_to_xml. > If this library is used as a libtool convenience library, then it is > likely the problem is due due to multiple occurances of common.o in > the package: > blade:src/im/gnutls-1.0.16% find . -name 'common.o' -print > ./lib/x509/.libs/common.o > ./lib/x509/common.o > ./src/common.o > Objects from libtool convenience libraries are extracted to individual > .o files prior to use so it is likely that this is why the linker > fails to see the symbols (two common.o files in the same library, > oops!). Well the lib/x509/common.c is in the library and the src/common.c is for the gnutls-cli and gnutls-serv programs. It seems like a bug in the linker. I cannot think of any linker that does not allow a file to be named the same in a library and program, though. > I did have to update a number of Makefile.am files in packages gnutils > depends on since the library dependencies were sometimes not > completely listed. Apparently the Linux linker will silently insert > library dependencies (recorded in the .so file), but this is not true > of most platforms so it is necessary to tell libtool about all > dependencies so they can be recorded in the .la file. Which dependencies did you have to add? > Bob -- Nikos Mavroyanopoulos From bfriesen at simple.dallas.tx.us Sun Jul 25 00:01:34 2004 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sat, 24 Jul 2004 17:01:34 -0500 (CDT) Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: <200407250014.38874.nmav@gnutls.org> References: <200407242103.38206.nmav@gnutls.org> <200407250014.38874.nmav@gnutls.org> Message-ID: On Sun, 25 Jul 2004, Nikos Mavroyanopoulos wrote: >> ./src/common.o >> Objects from libtool convenience libraries are extracted to individual >> .o files prior to use so it is likely that this is why the linker >> fails to see the symbols (two common.o files in the same library, >> oops!). > > Well the lib/x509/common.c is in the library and the src/common.c > is for the gnutls-cli and gnutls-serv programs. It seems like a bug > in the linker. I cannot think of any linker that does not allow a file > to be named the same in a library and program, though. The point is that if the x509 library is a libtool "convenience" library then its objects are extracted to regular .o files before linking the application. In this case it is not treated like a true archive library. Even if the bug was in the linker (doubtful), then gnutls must work around it since this linker has sucessfully linked tens of thousands of other libraries and programs and it is a component of a major platform. >> I did have to update a number of Makefile.am files in packages gnutils >> depends on since the library dependencies were sometimes not >> completely listed. Apparently the Linux linker will silently insert >> library dependencies (recorded in the .so file), but this is not true >> of most platforms so it is necessary to tell libtool about all >> dependencies so they can be recorded in the .la file. > > Which dependencies did you have to add? I will have to do some diffing against the original source packages in order to figure that out. Has gnutls only been built and tested under Linux? Bob ====================================== Bob Friesenhahn bfriesen at simple.dallas.tx.us http://www.simplesystems.org/users/bfriesen From nmav at gnutls.org Sun Jul 25 02:18:32 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun, 25 Jul 2004 03:18:32 +0300 Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: References: <200407250014.38874.nmav@gnutls.org> Message-ID: <200407250318.32198.nmav@gnutls.org> On Sunday 25 July 2004 01:01, you wrote: > The point is that if the x509 library is a libtool "convenience" > library then its objects are extracted to regular .o files before > linking the application. In this case it is not treated like a true > archive library. This looks like solaris-specific. Anyway are you aware if this is a libtool bug in this platform? Convenience libraries, were really convenient but if they are not portable I may replace them with direct compiling in other directories. > Has gnutls only been built and tested under Linux? Yes, this is my development platform. > Bob > ====================================== > Bob Friesenhahn > bfriesen at simple.dallas.tx.us > http://www.simplesystems.org/users/bfriesen -- Nikos Mavroyanopoulos From smurf at smurf.noris.de Sun Jul 25 03:29:17 2004 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Sun, 25 Jul 2004 03:29:17 +0200 Subject: [gnutls-dev] libtasn1 0.2.10 not in CVS ? In-Reply-To: <200407242057.05495.nmav@gnutls.org> References: <20040723083018.GS6949@kiste> <200407242057.05495.nmav@gnutls.org> Message-ID: <20040725012917.GB25055@kiste> Hi, Nikos Mavroyanopoulos: > > I noticed that libtasn1 0.2.10 is to be found at > > ftp://ftp.gnutls.org/pub/gnutls/libtasn1/, but the CVS repository ends > > with 0.2.9. > > Please fix. > This is not true. I just checked the web cvs repository and > seems fine to me. It's not tagged as such. @kiste libtasn1-cvs-rep $ rlog ChangeLog,v RCS file: ChangeLog,v Working file: ChangeLog head: 1.1 branch: 1.1.1 locks: strict access list: symbolic names: libtasn1_0_2_9: 1.1.1.1 libtasn1_0_2_8: 1.1.1.1 libtasn1_0_2_7: 1.1.1.1 libtasn1_0_2_6: 1.1.1.1 libtasn1_0_2_5: 1.1.1.1 libtasn1_0_2_4: 1.1.1.1 libtasn1_0_2_3: 1.1.1.1 libtasn1_0_2_2: 1.1.1.1 libtasn1_0_2_1: 1.1.1.1 libtasn1_0_2_0: 1.1.1.1 libtasn1_0_1_2: 1.1.1.1 gnutls_0_5_1: 1.1.1.1 gnutls_0_5_0: 1.1.1.1 libtasn1_0_1_1: 1.1.1.1 gnutls_0_4_with_libtasn1: 1.1.1.1 libtasn1_after_rename: 1.1.1.1 libasn1_0_1_0: 1.1.1.1 start: 1.1.1.1 asn1: 1.1.1 keyword substitution: kv total revisions: 2; selected revisions: 2 description: ---------------------------- revision 1.1 date: 2002/04/05 19:57:55; author: nmav; state: Exp; branches: 1.1.1; Initial revision ---------------------------- revision 1.1.1.1 date: 2002/04/05 19:57:55; author: nmav; state: Exp; lines: +0 -0 imported sources ============================================================================= -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de From bfriesen at simple.dallas.tx.us Sun Jul 25 03:58:50 2004 From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn) Date: Sat, 24 Jul 2004 20:58:50 -0500 (CDT) Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: <200407250318.32198.nmav@gnutls.org> References: <200407250014.38874.nmav@gnutls.org> <200407250318.32198.nmav@gnutls.org> Message-ID: On Sun, 25 Jul 2004, Nikos Mavroyanopoulos wrote: > On Sunday 25 July 2004 01:01, you wrote: > >> The point is that if the x509 library is a libtool "convenience" >> library then its objects are extracted to regular .o files before >> linking the application. In this case it is not treated like a true >> archive library. > This looks like solaris-specific. Anyway are you aware if this is a > libtool bug in this platform? Convenience libraries, were really convenient > but if they are not portable I may replace them with direct compiling in other > directories. It is a libtool shortcomming, but not necessarily specific to Solaris. Apparently the Linux (GNU) linker (or perhaps the 'ar' utility) does a better job of dealing with object files that have the same name. >> Has gnutls only been built and tested under Linux? > Yes, this is my development platform. Have you considered testing on other platforms? Bob ====================================== Bob Friesenhahn bfriesen at simple.dallas.tx.us http://www.simplesystems.org/users/bfriesen From nspring at cs.washington.edu Sun Jul 25 06:13:33 2004 From: nspring at cs.washington.edu (Neil Spring) Date: Sat, 24 Jul 2004 21:13:33 -0700 Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: References: <200407250014.38874.nmav@gnutls.org> <200407250318.32198.nmav@gnutls.org> Message-ID: On Jul 24, 2004, at 6:58 PM, Bob Friesenhahn wrote: > On Sun, 25 Jul 2004, Nikos Mavroyanopoulos wrote: >> On Sunday 25 July 2004 01:01, you wrote: >>> Has gnutls only been built and tested under Linux? >> Yes, this is my development platform. > > Have you considered testing on other platforms? I try to keep gnutls working on the mac. (I'm just a user though.) In that space -- could I ask that someone try to remove "#include " from wherever it appears? It's deprecated on freebsd and openbsd, and not present at all on my mac. I think gnutls itself is fine, but the opencdk it bundles has a few .c files that use it. I'd attach a patch, but the change is straightforward. thanks, -neil From nmav at gnutls.org Sun Jul 25 09:18:42 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun, 25 Jul 2004 10:18:42 +0300 Subject: [gnutls-dev] libtasn1 0.2.10 not in CVS ? In-Reply-To: <20040725012917.GB25055@kiste> References: <20040723083018.GS6949@kiste> <200407242057.05495.nmav@gnutls.org> <20040725012917.GB25055@kiste> Message-ID: <200407251018.42784.nmav@gnutls.org> On Sunday 25 July 2004 04:29, Matthias Urlichs wrote: > Hi, > > This is not true. I just checked the web cvs repository and > > seems fine to me. > It's not tagged as such. This is true. I've tagged the current version as 0_2_10. -- Nikos Mavroyanopoulos From nmav at gnutls.org Sun Jul 25 09:23:41 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun, 25 Jul 2004 10:23:41 +0300 Subject: [gnutls-dev] Problem linking gnutls 1.0.16 In-Reply-To: References: <200407250318.32198.nmav@gnutls.org> Message-ID: <200407251023.41903.nmav@gnutls.org> On Sunday 25 July 2004 04:58, Bob Friesenhahn wrote: > It is a libtool shortcomming, but not necessarily specific to Solaris. > Apparently the Linux (GNU) linker (or perhaps the 'ar' utility) does a > better job of dealing with object files that have the same name. > >> Has gnutls only been built and tested under Linux? > > Yes, this is my development platform. > Have you considered testing on other platforms? Testing on other platforms is done by developers and users that use gnutls on these platforms. I cannot afford doing extensive testing on all platforms. > > Bob > ====================================== > Bob Friesenhahn > bfriesen at simple.dallas.tx.us > http://www.simplesystems.org/users/bfriesen -- Nikos Mavroyanopoulos From badra at enst.fr Sun Jul 25 21:05:18 2004 From: badra at enst.fr (Mohamad Badra) Date: Sun, 25 Jul 2004 21:05:18 +0200 Subject: [gnutls-dev] gnutls-serv In-Reply-To: <200407251023.41903.nmav@gnutls.org> References: <200407250318.32198.nmav@gnutls.org> <200407251023.41903.nmav@gnutls.org> Message-ID: <4104046E.5050305@enst.fr> Hi list, When I use the folowing command, gnutls-serv -p xxxx --x509certfile filelocation, It tells me that reading 'filelocation' or 'null' Error: Error while readinfg file. Any help please? Nikos Mavroyanopoulos wrote: >On Sunday 25 July 2004 04:58, Bob Friesenhahn wrote: > > > >>It is a libtool shortcomming, but not necessarily specific to Solaris. >>Apparently the Linux (GNU) linker (or perhaps the 'ar' utility) does a >>better job of dealing with object files that have the same name. >> >> >>>>Has gnutls only been built and tested under Linux? >>>> >>>> >>>Yes, this is my development platform. >>> >>> >>Have you considered testing on other platforms? >> >> > >Testing on other platforms is done by developers and users that >use gnutls on these platforms. I cannot afford doing extensive >testing on all platforms. > > > >>Bob >>====================================== >>Bob Friesenhahn >>bfriesen at simple.dallas.tx.us >>http://www.simplesystems.org/users/bfriesen >> >> > > > -- Mohamad Badra ENST-Paris Dept. Computer Sciences and Networks From nmav at gnutls.org Mon Jul 26 12:41:10 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Mon, 26 Jul 2004 13:41:10 +0300 Subject: [gnutls-dev] gnutls-serv In-Reply-To: <4104046E.5050305@enst.fr> References: <200407251023.41903.nmav@gnutls.org> <4104046E.5050305@enst.fr> Message-ID: <200407261341.10330.nmav@gnutls.org> On Sunday 25 July 2004 22:05, Mohamad Badra wrote: > Hi list, > When I use the folowing command, > gnutls-serv -p xxxx --x509certfile filelocation, It tells me that > reading 'filelocation' or 'null' > Error: Error while readinfg file. You have to specify the x509keyfile as well. -- Nikos Mavroyanopoulos From algernon at bonehunter.rulez.org Wed Jul 28 10:10:00 2004 From: algernon at bonehunter.rulez.org (Gergely Nagy) Date: Wed, 28 Jul 2004 10:10:00 +0200 Subject: [gnutls-dev] gnutls_certificate_client_set_select_function vs _set_retrieve_function Message-ID: <1091002200.4543.6.camel@melkor> Hi! I have a program here that uses gnutls_certificate_client_set_select_function, which got deprecated, and produces a warning. I'd like to get rid of that warning and at the same time, allow those users who didn't upgrade their GnuTLS yet to compile my program even when only _set_select_function is available, and _set_retrieve_function is not. Is there an easy way to do that (other than a configure check, which for various reasons would be a bit of trouble)? And while I'm here - do I get it right, that unlike _set_select_function, which I used every time I created a gnutls_session, I should only use _set_retrieve_function once, after setting up the credentials-foo? TIA, -- Gergely Nagy From nmav at gnutls.org Wed Jul 28 12:03:37 2004 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Wed, 28 Jul 2004 13:03:37 +0300 Subject: [gnutls-dev] gnutls_certificate_client_set_select_function vs _set_retrieve_function In-Reply-To: <1091002200.4543.6.camel@melkor> References: <1091002200.4543.6.camel@melkor> Message-ID: <200407281303.37481.nmav@gnutls.org> On Wednesday 28 July 2004 11:10, Gergely Nagy wrote: > Hi! > I have a program here that uses > gnutls_certificate_client_set_select_function, which got deprecated, and > produces a warning. I'd like to get rid of that warning and at the same > time, allow those users who didn't upgrade their GnuTLS yet to compile > my program even when only _set_select_function is available, and > _set_retrieve_function is not. This function is deprecated because it will not be available in gnutls 1.2.0 (when released). All gnutls 1.0.x releases will be backwards compatible and will contain this function. If you just want to get rid of the warning you may add #define DEPRECATED before including gnutls.h. > And while I'm here - do I get it right, that unlike > _set_select_function, which I used every time I created a > gnutls_session, I should only use _set_retrieve_function once, after > setting up the credentials-foo? Yes. > TIA, -- Nikos Mavroyanopoulos From algernon at bonehunter.rulez.org Wed Jul 28 22:26:42 2004 From: algernon at bonehunter.rulez.org (Gergely Nagy) Date: Wed, 28 Jul 2004 22:26:42 +0200 Subject: [gnutls-dev] gnutls_certificate_client_set_select_function vs _set_retrieve_function In-Reply-To: <200407281303.37481.nmav@gnutls.org> References: <1091002200.4543.6.camel@melkor> <200407281303.37481.nmav@gnutls.org> Message-ID: <1091046402.18993.2.camel@melkor> > > I have a program here that uses > > gnutls_certificate_client_set_select_function, which got deprecated, and > > produces a warning. I'd like to get rid of that warning and at the same > > time, allow those users who didn't upgrade their GnuTLS yet to compile > > my program even when only _set_select_function is available, and > > _set_retrieve_function is not. > This function is deprecated because it will not be available in gnutls 1.2.0 > (when released). All gnutls 1.0.x releases will be backwards compatible > and will contain this function. If you just want to get rid of the warning you > may add #define DEPRECATED > before including gnutls.h. Mmmhm.. I think I'll just wait a bit then, until 1.0.13 gets into more places (namely Debian testing/sarge O:), and just bump the requirement. I don't want to be caught off-guard when 1.2.0 comes out ^_^" > > And while I'm here - do I get it right, that unlike > > _set_select_function, which I used every time I created a > > gnutls_session, I should only use _set_retrieve_function once, after > > setting up the credentials-foo? > Yes. Cool, thanks a lot! -- Gergely Nagy From smurf at smurf.noris.de Wed Jul 28 22:35:41 2004 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Wed, 28 Jul 2004 22:35:41 +0200 Subject: [gnutls-dev] gnutls_certificate_client_set_select_function vs _set_retrieve_function In-Reply-To: <1091046402.18993.2.camel@melkor> References: <1091002200.4543.6.camel@melkor> <200407281303.37481.nmav@gnutls.org> <1091046402.18993.2.camel@melkor> Message-ID: <20040728203541.GD27233@kiste> Hi, Gergely Nagy: > Mmmhm.. I think I'll just wait a bit then, until 1.0.13 gets into more > places (namely Debian testing/sarge O:), and just bump the requirement. That should happen tomorrow. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: