From enrico.scholz at informatik.tu-chemnitz.de Thu Mar 3 12:56:12 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 03 Mar 2005 12:56:12 +0100 Subject: [gnutls-dev] [opencdk] Uninitialized variable in tests/t-stream.c Message-ID: <874qft0wpv.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, somebody reported in https://bugzilla.redhat.com/beta/show_bug.cgi?id=149906 the following issue: | I just tried to compile package opencdk-0.5.5-1 from | Redhat Fedora Extras development tree. | | The compiler said | | t-stream.c(452): remark #592: variable "rc" is used before its value | is set | | The source code is | | int rc ; | | cdk_handle_new (&hd); | cdk_keydb_new (&db, CDK_DBTYPE_SK_KEYRING, "sec.gpg", 7); | cdk_strlist_add (&locusr, "twoaday at daredevil"); | //rc = cdk_file_clearsign (hd, locusr, file, "out.asc"); | if (rc) | printf ("clearsign_file %s: `%s'\n", file, cdk_strerror (rc)); | | Suggest init local variable "rc" before first use. Should the | commented out code be put back in ? This code is still in CVS. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From nmav at gnutls.org Mon Mar 7 09:27:48 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 7 Mar 2005 09:27:48 +0100 Subject: [gnutls-dev] [opencdk] Uninitialized variable in tests/t-stream.c In-Reply-To: <874qft0wpv.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <874qft0wpv.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <200503070927.48662.nmav@gnutls.org> On Thursday 03 March 2005 12:56, Enrico Scholz wrote: > Hello, > > somebody reported in > https://bugzilla.redhat.com/beta/show_bug.cgi?id=149906 > the following issue: Hello Enrico, Thank you for the bug report. I've commited a fix (i disabled this print) to the cvs. However this is in the test suite of opencdk and not really used by gnutls. > | I just tried to compile package opencdk-0.5.5-1 from > | Redhat Fedora Extras development tree. > | > | The compiler said > | > | t-stream.c(452): remark #592: variable "rc" is used before its value > | is set > | > | The source code is > | > | int rc ; > | > | cdk_handle_new (&hd); > | cdk_keydb_new (&db, CDK_DBTYPE_SK_KEYRING, "sec.gpg", 7); > | cdk_strlist_add (&locusr, "twoaday at daredevil"); > | //rc = cdk_file_clearsign (hd, locusr, file, "out.asc"); > | if (rc) > | printf ("clearsign_file %s: `%s'\n", file, cdk_strerror (rc)); > | > | Suggest init local variable "rc" before first use. Should the > | commented out code be put back in ? > > This code is still in CVS. > > > > > Enrico -- Nikos Mavrogiannopoulos From tim.ringenbach at comcast.net Thu Mar 10 00:10:11 2005 From: tim.ringenbach at comcast.net (Tim Ringenbach) Date: Wed, 09 Mar 2005 17:10:11 -0600 Subject: [gnutls-dev] gnutls's sonames Message-ID: <422F8253.6080503@comcast.net> Hi, I'm trying to improve gaim's (http://gaim.sf.net) autopackage (http://autopackage.org). Our ssl support is done via plugins, so we have a ssl-nss.so plugin for mozilla nss, and a ssl-gnutls.so for gnutls. The autopackage compiles both, and whatever is available at runtime is used. Currently, the ssl-gnutls plugin depends upon libgnutls.so.11. However, many people have a version of gnutls with a different soname, such as libgnutls.so.10 or libgnutls.so.7, and I hear a libgnutls.so.12 is out now too. What I'm probably going to do is build multiple versions of the plugin against each version of gnutls. So I'll have a ssl-gnutls10.so and a ssl-gnutsl11.so, etc. I expect setting up the build environment for this will be a bit tricky though. What is bound to make it even trickier though, is that you don't seem to document when you change your soname. Your version numbers seem to have nothing to do with your so version, and your NEWS doesn't seem to mention anything about such changes. So I have no idea what versions of gnutls I need. So what's up with this? Is this documented somewhere I can't find, or why isn't it documented? Also any tips on setting up a build enviroment for what I'm wanting to do? --Tim Ringenbach From jas at extundo.com Thu Mar 10 15:15:08 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 10 Mar 2005 15:15:08 +0100 Subject: [gnutls-dev] Re: gnutls's sonames In-Reply-To: <422F8253.6080503@comcast.net> (Tim Ringenbach's message of "Wed, 09 Mar 2005 17:10:11 -0600") References: <422F8253.6080503@comcast.net> Message-ID: Tim Ringenbach writes: > Hi, Hello! > Our ssl support is done via plugins, so we have a ssl-nss.so plugin for > mozilla nss, and a ssl-gnutls.so for gnutls. The autopackage compiles > both, and whatever is available at runtime is used. > > Currently, the ssl-gnutls plugin depends upon libgnutls.so.11. However, > many people have a version of gnutls with a different soname, such as > libgnutls.so.10 or libgnutls.so.7, and I hear a libgnutls.so.12 is out > now too. Yup. I think GnuTLS 1.1.x and 1.2.x uses libgnutls.so.12.1, and GnuTLS 1.0.x uses libgnutls.so.11.1. As such, libgnutls.so.12 is supposed to be ABI compatible with libgnutls.so.11, according to GNU ld and the GNU Libtool philosophy, if I understand things correctly. I'm not sure how rigorously this has been enforced or checked in GnuTLS though. > What I'm probably going to do is build multiple versions of the plugin > against each version of gnutls. So I'll have a ssl-gnutls10.so and a > ssl-gnutsl11.so, etc. I expect setting up the build environment for this > will be a bit tricky though. Are you sure the libraries aren't sufficiently ABI compatible for your needs? > What is bound to make it even trickier though, is that you don't seem to > document when you change your soname. Your version numbers seem to have > nothing to do with your so version, and your NEWS doesn't seem to > mention anything about such changes. So I have no idea what versions of > gnutls I need. > > So what's up with this? Is this documented somewhere I can't find, or > why isn't it documented? First, review this link: http://www.gnu.org/software/libtool/manual.html#Versioning That is the philosophy I will be using for 1.2.x. I will add a API/ABI section in NEWS for every future 1.2.x release. I can't speak for older releases, perhaps Nikos knows. If you want to do some archeology on the CVS server, and document what you find, that would be a useful contribution! Could be added as a section in the manual, for instance. > Also any tips on setting up a build enviroment for what I'm wanting to do? Perhaps you could consider dlopen libgnutls.so. Regards, Simon From tim.ringenbach at comcast.net Fri Mar 11 01:29:28 2005 From: tim.ringenbach at comcast.net (Tim Ringenbach) Date: Thu, 10 Mar 2005 18:29:28 -0600 Subject: [gnutls-dev] Re: gnutls's sonames In-Reply-To: References: <422F8253.6080503@comcast.net> Message-ID: <4230E668.1060609@comcast.net> Simon Josefsson wrote: > Tim Ringenbach writes: > >>Our ssl support is done via plugins, so we have a ssl-nss.so plugin for >>mozilla nss, and a ssl-gnutls.so for gnutls. The autopackage compiles >>both, and whatever is available at runtime is used. >> >>Currently, the ssl-gnutls plugin depends upon libgnutls.so.11. However, >>many people have a version of gnutls with a different soname, such as >>libgnutls.so.10 or libgnutls.so.7, and I hear a libgnutls.so.12 is out >>now too. > > > Yup. > > I think GnuTLS 1.1.x and 1.2.x uses libgnutls.so.12.1, and GnuTLS > 1.0.x uses libgnutls.so.11.1. > > As such, libgnutls.so.12 is supposed to be ABI compatible with > libgnutls.so.11, according to GNU ld and the GNU Libtool philosophy, > if I understand things correctly. I'm not sure how rigorously this > has been enforced or checked in GnuTLS though. I don't think you understand things correctly. I'm not sure I understand everything right either, but I'll try my best to explain things as I understand them. A program, (or another .so), links against an .soname. You cannot link against libgnutls.so.12 OR libgnutls.so.11, you must link against one, or the other, or both (where both means needing both versions or the program won't start, which is obviously not what we want). Maybe you're confusing an soname with what you tell libtool the revision is? They are two different things, libtool does some kind of transformation before writing the filename. Using viewcvs, i see you currently have in configure.in: LT_CURRENT=13 LT_REVISION=25 LT_AGE=1 If I understand things right, that causes you to end up with a filename of libgnutls.so.12.1.25 and an soname of libgnutls.so.12 When ldconfig is run, it makes a symlink from the actual filename (libgnutls.so.12.1.25) to the soname (libgnutls.so.12). For example, on my system (fc3), I have: ls -l /usr/lib/libgnutls.so* -l lrwxrwxrwx 1 root root 20 Feb 25 16:06 /usr/lib/libgnutls.so -> libgnutls.so.11.1.20 lrwxrwxrwx 1 root root 20 Feb 21 00:13 /usr/lib/libgnutls.so.11 -> libgnutls.so.11.1.20 -rwxr-xr-x 1 root root 448084 Sep 21 11:29 /usr/lib/libgnutls.so.11.1.20 Now if I do "objdump -p /usr/lib/libgnutls.so.11.1.20 |grep SONAME" I get: SONAME libgnutls.so.11 >>What I'm probably going to do is build multiple versions of the plugin >>against each version of gnutls. So I'll have a ssl-gnutls10.so and a >>ssl-gnutsl11.so, etc. I expect setting up the build environment for this >>will be a bit tricky though. > > > Are you sure the libraries aren't sufficiently ABI compatible for your > needs? They are for Gaim's purposes. It doesn't use a whole lot of the API, and compiles fine with gnutls7 through 11 I know, and probably 12 too. But they have different sonames. As for as the runtime linker is concerned, they are totally incompatable. If a binary linked against libgnutls.so.12 is attempted to be loaded on a system with only libgnutls.so.11, it will simply fail. In our case, when we try to dlopen our plugin, we'll get an error, and gaim won't have ssl support, won't be able to log into msn, etc. If it was the gaim binary linked against gnutls12 (instead of just the plugin), then gaim would refuse to start. That's why my only options are dlopen or building the plugin multiple times. >>What is bound to make it even trickier though, is that you don't seem to >>document when you change your soname. Your version numbers seem to have >>nothing to do with your so version, and your NEWS doesn't seem to >>mention anything about such changes. So I have no idea what versions of >>gnutls I need. >> >>So what's up with this? Is this documented somewhere I can't find, or >>why isn't it documented? > > > First, review this link: > > http://www.gnu.org/software/libtool/manual.html#Versioning > > That is the philosophy I will be using for 1.2.x. I will add a > API/ABI section in NEWS for every future 1.2.x release. Thanks, that would be helpful. Of course, breaking abi compatalbity less often would be even better ;) Mike Hearn wrote an (unfinished) article on writing shared libraries, you can find it at: http://navi.cx/~mike/writing-shared-libraries.html As I recall he wanted to call it "best practices", but no one currently follows many of them. > I can't speak for older releases, perhaps Nikos knows. If you want to > do some archeology on the CVS server, and document what you find, that > would be a useful contribution! Could be added as a section in the > manual, for instance. I asked a friend in #gaim and he was kind enough to look it up for me using rpmfind.net or something: gnutls 0.9.91 => libgnutls.so.8 gnutls 0.8.10 => libgnutls.so.7 gnutls 1.0.8 => libgnutls.so.10 I think those are just random versions with those sonames though, not the first, nor the latest. Thanks for your help and the friendly reply, --Tim From nmav at gnutls.org Fri Mar 11 08:44:15 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Mar 2005 08:44:15 +0100 Subject: [gnutls-dev] Re: gnutls's sonames In-Reply-To: <4230E668.1060609@comcast.net> References: <422F8253.6080503@comcast.net> <4230E668.1060609@comcast.net> Message-ID: <200503110844.16370.nmav@gnutls.org> On Friday 11 March 2005 01:29, Tim Ringenbach wrote: Hello, > Thanks, that would be helpful. Of course, breaking abi compatalbity less > often would be even better ;) This is a goal set from the beginning of the project but sometimes this could be achieved. Since now the project is considered stable we shouldn't have problems with it. > > I can't speak for older releases, perhaps Nikos knows. If you want to > > do some archeology on the CVS server, and document what you find, that > > would be a useful contribution! Could be added as a section in the > > manual, for instance. > I asked a friend in #gaim and he was kind enough to look it up for me > using rpmfind.net or something: > gnutls 0.9.91 => libgnutls.so.8 > gnutls 0.8.10 => libgnutls.so.7 > gnutls 1.0.8 => libgnutls.so.10 Yes this is indeed the case. I tried to increase the so number only during major releases (from 0.7->0.8->0.9->1.0). Unfortunately somewhere near 1.0.4 we needed to change the transport_ptr from integer to pointer, a change that breaks the abi in 64 bit machines. So all 1.0.x releases after x>4 have a soname of 10 instead of 9. However you shouldn't be concerned with x<=4 or gnutls 0.8.y because of several other problems they had. > --Tim -- Nikos Mavrogiannopoulos From wk at gnupg.org Fri Mar 11 20:05:01 2005 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Mar 2005 20:05:01 +0100 Subject: [gnutls-dev] Re: gnutls's sonames In-Reply-To: <4230E668.1060609@comcast.net> (Tim Ringenbach's message of "Thu, 10 Mar 2005 18:29:28 -0600") References: <422F8253.6080503@comcast.net> <4230E668.1060609@comcast.net> Message-ID: <87sm32c8bm.fsf@wheatstone.g10code.de> On Thu, 10 Mar 2005 18:29:28 -0600, Tim Ringenbach said: > If I understand things right, that causes you to end up with a > filename of libgnutls.so.12.1.25 and an soname of libgnutls.so.12 > When ldconfig is run, it makes a symlink from the actual filename > (libgnutls.so.12.1.25) to the soname (libgnutls.so.12). Correct (for glibc based systems). > Mike Hearn wrote an (unfinished) article on writing shared libraries, > you can find it at: http://navi.cx/~mike/writing-shared-libraries.html Every author of a shared library should have read Ulrich Drepper's paper in this: http://people.redhat.com/drepper/dsohowto.pdf and if time permits: http://people.redhat.com/drepper/goodpractice.pdf Although they concentrate on GNU/Linux the general things are valid for all systems. Shalom-Salam, Werner From torsten at debian.org Fri Mar 11 23:06:46 2005 From: torsten at debian.org (Torsten Landschoff) Date: Fri, 11 Mar 2005 23:06:46 +0100 Subject: [gnutls-dev] Non blocking I/O Message-ID: <20050311220646.GA9609@stargate.galaxy> Hi there, As the Debian Maintainer of OpenLDAP I am trying to port that beast from OpenSSL to GnuTLS. Big problem: It is using non blocking I/O. It seems like OpenSSL deals with the resulting complication under the hood. From the GnuTLS documentation it seems like I have to redo an interrupted send/recv with exactly the same parameters. Which makes the application code quite complicated and really does not fit well into OpenLDAP. I wonder if that is true. If it is - do I have to pass the same address of the buffer or is it okay to copy the data somewhere else for the second iteration? IOW: Can I do ssize_t s = gnutls_record_send(session, buffer, size); if (s == GNUTLS_E_AGAIN) { void *new_buffer = malloc(size); memcpy(new_buffer, buffer, size); } gnutls_record_send(session, new_buffer, size); or is that not even necessary and I can do ssize_t s = gnutls_record_send(session, buffer, size); if (s == GNUTLS_E_AGAIN) gnutls_record_send(session, NULL, 0); and know that GnuTLS has an internal copy of my data? Also it seems like I have to maintain a "virtual state" or "wanted state" of the sockets storing the information that a handshake is pending and gnutls_handshake has to be invoked again!? Or will a handshake continue if I am trying to send or receive data? Sorry for the dumb questions, I am quite new to GnuTLS and want to get it right the first time. Thanks Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From smurf at smurf.noris.de Sat Mar 12 06:26:40 2005 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Sat, 12 Mar 2005 06:26:40 +0100 Subject: [gnutls-dev] gnutls's sonames In-Reply-To: <422F8253.6080503@comcast.net> References: <422F8253.6080503@comcast.net> Message-ID: <20050312052640.GA30444@kiste> Hi, Tim Ringenbach: > What I'm probably going to do is build multiple versions of the plugin > against each version of gnutls. So I'll have a ssl-gnutls10.so and a > ssl-gnutsl11.so, etc. I expect setting up the build environment for this > will be a bit tricky though. > Your system should have a /usr/lib/lbgnutls.so file (which corresponds to the headers installed in /usr/include). You link against that. Why would you care about the library's soname? The linker does the Right Thing for you. You cannot build against other libgnutls versions anyway, because you don't have the corresponding C header files installed. -- 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 Mar 12 11:57:33 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 12 Mar 2005 11:57:33 +0100 Subject: [gnutls-dev] Non blocking I/O In-Reply-To: <20050311220646.GA9609@stargate.galaxy> References: <20050311220646.GA9609@stargate.galaxy> Message-ID: <200503121157.33477.nmav@gnutls.org> On Friday 11 March 2005 23:06, Torsten Landschoff wrote: > Hi there, Hello, (this reply is written in haste so it might not really address your problems, please ask again in that case). > As the Debian Maintainer of OpenLDAP I am trying to port that beast from > OpenSSL to GnuTLS. Big problem: It is using non blocking I/O. It seems > like OpenSSL deals with the resulting complication under the hood. > From the GnuTLS documentation it seems like I have to redo an > interrupted send/recv with exactly the same parameters. Which makes the > application code quite complicated and really does not fit well into > OpenLDAP. You can also pass null pointers in that case. If it isn't in the documentation i need to fix it. > and know that GnuTLS has an internal copy of my data? Yes, gnutls has already an internal copy (encrypted and authenticated). > Also it seems like I have to maintain a "virtual state" or "wanted > state" of the sockets storing the information that a handshake is > pending and gnutls_handshake has to be invoked again!? Or will a > handshake continue if I am trying to send or receive data? No it will not. You will have to call gnutls_handshake() until it returns zero. > > Sorry for the dumb questions, I am quite new to GnuTLS and want to get > it right the first time. > > Thanks > Torsten -- Nikos Mavrogiannopoulos From tim.ringenbach at comcast.net Sat Mar 12 14:30:01 2005 From: tim.ringenbach at comcast.net (Tim Ringenbach) Date: Sat, 12 Mar 2005 07:30:01 -0600 Subject: [gnutls-dev] gnutls's sonames In-Reply-To: <20050312052640.GA30444@kiste> References: <422F8253.6080503@comcast.net> <20050312052640.GA30444@kiste> Message-ID: <4232EED9.8000703@comcast.net> Matthias Urlichs wrote: > Your system should have a /usr/lib/lbgnutls.so file (which corresponds > to the headers installed in /usr/include). You link against that. Yes, it does. I know this. > Why would you care about the library's soname? The linker does the > Right Thing for you. Because I'm building an autopackage, as I said earlier. People trying to install it will have different versions of gnutls. Right now, it insists the user either have mozilla nss, or gnutls11. If they have neither (or if mozilla nss is installed some place we can't find, like it commonly is), the autopackage refuses to install, because things wouldn't work. > You cannot build against other libgnutls versions anyway, because you > don't have the corresponding C header files installed. Yeah, I figured I would install several additional versions of gnutls in private prefixes, and use those to link against. Unless gnutls is parallel installable, but I don't think it is. I know whenever e.g. gtk, changes its soname, they make the library parallel installable, so you can have gtk1.2 and gtk2.0 installed to the same prefix and build applications against both. From smurf at smurf.noris.de Sat Mar 12 15:39:53 2005 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Sat, 12 Mar 2005 15:39:53 +0100 Subject: [gnutls-dev] gnutls's sonames In-Reply-To: <4232EED9.8000703@comcast.net> References: <422F8253.6080503@comcast.net> <20050312052640.GA30444@kiste> <4232EED9.8000703@comcast.net> Message-ID: <20050312143953.GB8986@kiste> Hi, Thanks for the explanation. So you'd ship many versions of your lib, linked against different gnutls versions, and then use the one that actually works on the system in question -- correct? Tim Ringenbach: > Yeah, I figured I would install several additional versions of gnutls in > private prefixes, and use those to link against. Unless gnutls is > parallel installable, but I don't think it is. The library itself is, but the development headers plus linkable .so lib isn't. > I know whenever e.g. gtk, changes its soname, They didn't just change the soname -- they changed the whole library name. The gtk people had a point, though -- gtk1.2 and gtk2 are essentially different libraries, not just the same library with a few minor changes or extensions. -- 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 tim.ringenbach at comcast.net Sat Mar 12 16:00:05 2005 From: tim.ringenbach at comcast.net (Tim Ringenbach) Date: Sat, 12 Mar 2005 09:00:05 -0600 Subject: [gnutls-dev] gnutls's sonames In-Reply-To: <20050312143953.GB8986@kiste> References: <422F8253.6080503@comcast.net> <20050312052640.GA30444@kiste> <4232EED9.8000703@comcast.net> <20050312143953.GB8986@kiste> Message-ID: <423303F5.7040300@comcast.net> Matthias Urlichs wrote: > Hi, > > Thanks for the explanation. So you'd ship many versions of your lib, > linked against different gnutls versions, and then use the one that > actually works on the system in question -- correct? Yeah that's the current plan. Except it's a plugin, not a library. So gaim is g_module_open()ing (which is just glib's dlopen wrapper) all the plugins it finds anyway. The loading would just fail all but the plugin who's version of gnutls is installed. Alternatively, I could just build one plugin and have the plugin dlopen gnutls, trying several versions it knows it works with. I could even use Mike Hearn's relaytool to do this without having to change the code to use function pointers anyway. But the other gaim developers seem to think the multiple gnutls plugins approch is better. --Tim From stamer at gaos.org Thu Mar 17 12:05:24 2005 From: stamer at gaos.org (Heiko Stamer) Date: Thu, 17 Mar 2005 12:05:24 +0100 Subject: [gnutls-dev] `make check` failure on Solaris 2.7 Message-ID: <20050317110524.GA27903@flower.theory.informatik.uni-kassel.de> Hello gnutls-team, during the build of the gnutls 1.2.0 tests on sparc/SunOS 5.7 (Solaris 2.7) platform the following error occured. It seems to me that the necessary linker switch "-lresolv" is missing (or was not properly configured). However, the installed library works fine. stamer:tests$ make check make simple anonself openssl \ pkcs12_neon make[1]: Entering directory `/home/stamer/src/gnutls-1.2.0/tests' make[1]: `simple' is up to date. /bin/ksh ../libtool --tag=CC --mode=link gcc -O3 -msupersparc -DSYSV -DSVR4 -I/usr/openwin/include -I/usr/dt/include -I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -pipe -I/home/stamer/include -I/home/stamer/include -no-install -L/usr/lib -L/usr/openwin/lib -L/usr/dt/lib -L/usr/local/lib -L/home/stamer/lib -o anonself anonself.o ../lib/libgnutls.la libutils.la -lz gcc -O3 -msupersparc -DSYSV -DSVR4 -I/usr/openwin/include -I/usr/dt/include -I/usr/local/include -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -pipe -I/home/stamer/include -I/home/stamer/include -o anonself anonself.o -L/usr/lib -L/usr/openwin/lib -L/usr/dt/lib -L/usr/local/lib -L/home/stamer/lib ../lib/.libs/libgnutls.so /home/stamer/lib/libgcrypt.so -lnsl -lsocket /home/stamer/lib/libgpg-error.so ./.libs/libutils.a -lz -R/home/stamer/src/gnutls-1.2.0/lib/.libs -R/home/stamer/lib -R/home/stamer/lib Undefined first referenced symbol in file inet_ntop anonself.o inet_pton anonself.o ld: fatal: Symbol referencing errors. No output written to anonself collect2: ld returned 1 exit status make[1]: *** [anonself] Error 1 make[1]: Leaving directory `/home/stamer/src/gnutls-1.2.0/tests' make: *** [check-am] Error 2 If you need further details for fixing this bug, don't hesitate to ask me. Yours respectfully, -- Heiko Stamer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available URL: From jas at extundo.com Thu Mar 17 14:42:56 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 17 Mar 2005 14:42:56 +0100 Subject: [gnutls-dev] Re: `make check` failure on Solaris 2.7 In-Reply-To: <20050317110524.GA27903@flower.theory.informatik.uni-kassel.de> (Heiko Stamer's message of "Thu, 17 Mar 2005 12:05:24 +0100") References: <20050317110524.GA27903@flower.theory.informatik.uni-kassel.de> Message-ID: Heiko Stamer writes: > Hello gnutls-team, > > during the build of the gnutls 1.2.0 tests on sparc/SunOS 5.7 (Solaris 2.7) > platform the following error occured. It seems to me that the necessary > linker switch "-lresolv" is missing (or was not properly configured). My SunOS 5.9 man page suggest -lsocket -lnsl is the appropriate switches: cc [ flag ... ] file ... -lsocket -lnsl [ library ... ] Is this different in 5.7? I'll try to write a good autoconf test for this. It seems it is slightly more complicated than merely AC_CHECK_LIB(nsl, inet_ntop,,, -lsocket). Or maybe it isn't.. Thanks, Simon From gnutls-dev at mlists.thewrittenword.com Thu Mar 17 17:52:56 2005 From: gnutls-dev at mlists.thewrittenword.com (Albert Chin) Date: Thu, 17 Mar 2005 10:52:56 -0600 Subject: [gnutls-dev] Non blocking I/O In-Reply-To: <20050311220646.GA9609@stargate.galaxy> References: <20050311220646.GA9609@stargate.galaxy> Message-ID: <20050317165256.GA58813@mail1.thewrittenword.com> On Fri, Mar 11, 2005 at 11:06:46PM +0100, Torsten Landschoff wrote: > As the Debian Maintainer of OpenLDAP I am trying to port that beast from > OpenSSL to GnuTLS. Big problem: It is using non blocking I/O. It seems > like OpenSSL deals with the resulting complication under the hood. Someone posted a patch for this in 2003: http://www.openldap.org/lists/openldap-devel/200307/msg00003.html Maybe their work can help you. -- albert chin (china at thewrittenword.com) From torsten at debian.org Thu Mar 17 19:06:44 2005 From: torsten at debian.org (Torsten Landschoff) Date: Thu, 17 Mar 2005 19:06:44 +0100 Subject: [gnutls-dev] Non blocking I/O In-Reply-To: <20050317165256.GA58813@mail1.thewrittenword.com> References: <20050311220646.GA9609@stargate.galaxy> <20050317165256.GA58813@mail1.thewrittenword.com> Message-ID: <20050317180643.GB5667@stargate.galaxy> Hi Albert, On Thu, Mar 17, 2005 at 10:52:56AM -0600, Albert Chin wrote: > On Fri, Mar 11, 2005 at 11:06:46PM +0100, Torsten Landschoff wrote: > > As the Debian Maintainer of OpenLDAP I am trying to port that beast from > > OpenSSL to GnuTLS. Big problem: It is using non blocking I/O. It seems > > like OpenSSL deals with the resulting complication under the hood. > > Someone posted a patch for this in 2003: > http://www.openldap.org/lists/openldap-devel/200307/msg00003.html > > Maybe their work can help you. That's the patch that's already in the old Debian package since 2.1.x of OpenLDAP and causes more problems than it solves. I am working to replace that patch which is trying to implement an OpenSSL like wrapper around GnuTLS which I am trying to avoid since it seems to me like the GnuTLS API is more slim than OpenSSL. Greetings Torsten -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: