Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On Aug 25 23:36, Charles Wilson wrote: On 8/21/2010 4:54 AM, Corinna Vinschen wrote: The question is, why does libtirpc declare the functions at all? Does it come with its own implementation? Yes, it does. And, that implementation is used by the upstream source for linux, in preference to the glibc-provided version. Any idea, why? I assume it really needs bindresvport_sa to support the bindresvport functionality for IPv6, which is not supported by glibc. But it is supported on Cygwin, BSD, and others. So, is that a configurable option? In other words, does libtirpc configury check for these functions on the target system? I followed that pattern in libtirpc, as well: the libtirpc version is used in preference to cygwin's. Not because I think there is a problem with cygwin's, but simply because I followed the linux pattern. Given that, I think something similar to the krb5 solution could be used here, as well. Unfortunately, the current cygtirpc-1.dll exports its version of bindresvport and bindresvport_sa. That is a *problem* because anything built against it will expect to use ITS version from now on. Not much of a problem, I guess. Given that the application is linked against cygtirpc-1.dll anyway, it doesn't matter if it uses the libtirpc or the cygwin implementation, same as on Linux. At least not as long as the cygtirpc-1.dll functions work correct. Unless I rebuild with renamed versions, and bump the API number. Or, don't bump the API number and break stuff. Since it is a new package, and so far only Erick's private libvirt seems to use it, I'm actually leaning that way. Eric, any thoughts? Whether or not, I think the problem are the libtirpc headers in the first place. OK. Given the above, I think that the libtirpc headers just shouldn't declare these functions on systems providing them via netdb.h. But note that this only occurs with -Wredundant-decls, which is not one of the default warnings. right, but this problem did lead to the discovery of a real issue in cygtirpc-1.dll... I wonder if there are more issues lurking here: The following are exported by both cygtirpc-1.dll and cygwin1.dll: bindresvport bindresvport_sa getpeereid (*) (*) implemented using error = getsockopt(s, SOL_SOCKET, SO_PEERCRED, uc, uclen); and then picking uc.uid and uc.gid (after error checking, etc). Cygwin implements both APIs of getting the peer credentials, so the libtirpc implementation of getpeereid is redundant, but should work. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 8/26/2010 4:26 AM, Corinna Vinschen wrote: On Aug 25 23:36, Charles Wilson wrote: On 8/21/2010 4:54 AM, Corinna Vinschen wrote: The question is, why does libtirpc declare the functions at all? Does it come with its own implementation? Yes, it does. And, that implementation is used by the upstream source for linux, in preference to the glibc-provided version. Any idea, why? I assume it really needs bindresvport_sa to support the bindresvport functionality for IPv6, which is not supported by glibc. But it is supported on Cygwin, BSD, and others. So, is that a configurable option? In other words, does libtirpc configury check for these functions on the target system? No, it doesn't. Unfortunately, the current cygtirpc-1.dll exports its version of bindresvport and bindresvport_sa. That is a *problem* because anything built against it will expect to use ITS version from now on. Not much of a problem, I guess. Given that the application is linked against cygtirpc-1.dll anyway, it doesn't matter if it uses the libtirpc or the cygwin implementation, same as on Linux. At least not as long as the cygtirpc-1.dll functions work correct. Well, it's a problem if I want to remove or rename the duplicate functions now provided by cygtirpc-1.dll. Given the above, I think that the libtirpc headers just shouldn't declare these functions on systems providing them via netdb.h. But that's quite difficult to implement, in practice. You can't do this: #ifndef HAVE_BINDRESVPORT declare bindresvport #endif in an installed header, because then you'd ALSO have to install and #include your version of config.h, which is a big no-no. Not to mention the namespace conflicts inherent in the autoconf-generated HAVE_* macros. So, you have to make this header an AC_OUTPUT() file, and arrange to somehow munge rpc/rpc.h.in to DTRT depending on the value of HAVE_BINDRESVPORT... It is *doable* -- but not simple. The following are exported by both cygtirpc-1.dll and cygwin1.dll: bindresvport bindresvport_sa getpeereid (*) Cygwin implements both APIs of getting the peer credentials, so the libtirpc implementation of getpeereid is redundant, but should work. Yes, but I don't really like hiding the official implementation for no good reason. OTOH, that's what libtirpc does on linux -- my original justification for doing it this way. I'm of two minds on this. On the one hand: Notwithstanding the rpc/rpc.h re-declaration problem, I'd rather either (a) rename these functions -- which breaks ABI back-compat, or (b) remove them entirely from the build, which does that too -- but also forces libtirpc itself to use cygwin's implementation. Assuming it works, I'd rather go with (b). And not bump the DLL version number, since libtirpc is so young. But breaking the ABI without bumping the DLL number is bad form, and this is all a lot more work than just: On the other hand, Just do it the way it is done on linux, and simply fix the header redeclaration problem. That's less work :-) Regardless of how I deal with the duplicate symbols, fixing the rpc/rpc.h re-declaration problem implies substantial changes to the cygport and patches, so it'll take some time to get it right...especially given other urgent demands on my time right now (updated cygutils, run, run2; deadline approaching for official libtool-2.2.next, ...) -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 08/25/2010 09:36 PM, Charles Wilson wrote: Unless I rebuild with renamed versions, and bump the API number. Or, don't bump the API number and break stuff. Since it is a new package, and so far only Erick's private libvirt seems to use it, I'm actually leaning that way. Eric, any thoughts? libtirpc is new enough, and I haven't distributed my built libvirt anywhere, that I would be just fine with a -2 without a new API number, if that makes life easier for you. Ultimately, I do plan on doing an ITP for libvirt. Right now, we don't really have any native VMs like qemu working under cygwin, and kvm is out of the question without access to the kernel; but a cygwin-built libvirt _is_ capable of doing remote control of VMs hosted on another machine. But the ITP can wait until we are happy with the libtirpc situation. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 8/21/2010 4:54 AM, Corinna Vinschen wrote: On Aug 20 21:07, Charles Wilson wrote: If you concur, I'll post a patch to that effect to cygwin-patches (we use our own header, not newlib's, for netinet/in.h). This is not the right solution. OK. First, we don't support _BSD_SOURCE and _GNU_SOURCE, yet, since, as you can see in the comment in /usr/include/features.h, the groundwork is entirely missing. The _POSIX_SOURCE is used in newlib in the first place and we can and do use it as well. _XOPEN_SOURCE is only barely available for a few months now, but it's not actually used anywhere. I see. On Linux, bindresvport and bindresvport6 are available by default, *unless* you define something like _POSIX_SOURCE. Right...as you pointed out below, you get the same warning on linux. Since newlib/Cygwin is missing the groundwork for a full-fledged features.h, your above suggestion would result in declaring bindresvport/bindresvport_sa *only if* the user explicitely defines _BSD_SOURCE or _GNU_SOURCE on the command line. That's not feasible. Yes, you are correct. :-( The question is, why does libtirpc declare the functions at all? Does it come with its own implementation? Yes, it does. And, that implementation is used by the upstream source for linux, in preference to the glibc-provided version. I followed that pattern in libtirpc, as well: the libtirpc version is used in preference to cygwin's. Not because I think there is a problem with cygwin's, but simply because I followed the linux pattern. Given that, I think something similar to the krb5 solution could be used here, as well. Unfortunately, the current cygtirpc-1.dll exports its version of bindresvport and bindresvport_sa. That is a *problem* because anything built against it will expect to use ITS version from now on. Unless I rebuild with renamed versions, and bump the API number. Or, don't bump the API number and break stuff. Since it is a new package, and so far only Erick's private libvirt seems to use it, I'm actually leaning that way. Eric, any thoughts? Whether or not, I think the problem are the libtirpc headers in the first place. OK. But note that this only occurs with -Wredundant-decls, which is not one of the default warnings. right, but this problem did lead to the discovery of a real issue in cygtirpc-1.dll... I wonder if there are more issues lurking here: The following are exported by both cygtirpc-1.dll and cygwin1.dll: bindresvport bindresvport_sa getpeereid (*) (*) implemented using error = getsockopt(s, SOL_SOCKET, SO_PEERCRED, uc, uclen); and then picking uc.uid and uc.gid (after error checking, etc). Note that there are a number of functions declared by cygwin's netdb.h header, but are provided by cygtirpc: voidendrpcent (void); struct rpcent *getrpcent (void); struct rpcent *getrpcbyname (const char *); struct rpcent *getrpcbynumber (int); voidsetrpcent (int); Interestingly, many of these apparently HAD been declared in tirpc/rpc/rpcent.h, but were commented out (using C++ comment markers, I might add). But, at least that means there is no conflict with these symbols. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On Aug 20 21:07, Charles Wilson wrote: On 8/20/2010 8:35 PM, Eric Blake wrote: In file included from ././remote/qemu_protocol.h:9, from remote/qemu_protocol.c:7: /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:21: warning: previous declaration of 'bindresvport' was here /usr/include/tirpc/rpc/rpc.h:95: warning: redundant redeclaration of 'bindresvport_sa' [-Wredundant-decls] /usr/include/netinet/in.h:22: warning: previous declaration of 'bindresvport_sa' was here Well, looking at linux, the declarations in netinet/in.h are guarded by #if defined __USE_MISC || defined __USE_GNU These symbols are activated in (linux's) features.h by: #if defined _BSD_SOURCE || defined _SVID_SOURCE # define __USE_MISC 1 #endif #ifdef _GNU_SOURCE # define __USE_GNU 1 #endif Given that the only *SOURCE flags supported by cygwin's headers are: _BSD_SOURCE _POSIX_SOURCE _XOPEN_SOURCE _GNU_SOURCE (and, the newlib headers don't employ the __USE_* indirection), I think the correct fix is to modify cygwin's netinet/in.h to add the following guard around the declaration of bindresvport and bindresvport_sa: #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE) If you concur, I'll post a patch to that effect to cygwin-patches (we use our own header, not newlib's, for netinet/in.h). This is not the right solution. First, we don't support _BSD_SOURCE and _GNU_SOURCE, yet, since, as you can see in the comment in /usr/include/features.h, the groundwork is entirely missing. The _POSIX_SOURCE is used in newlib in the first place and we can and do use it as well. _XOPEN_SOURCE is only barely available for a few months now, but it's not actually used anywhere. However bindresvport and bindresvport_sa are guarded, they are part of the official system header netinet/in.h, and they exist in Cygwin. On Linux, bindresvport and bindresvport6 are available by default, *unless* you define something like _POSIX_SOURCE. Since newlib/Cygwin is missing the groundwork for a full-fledged features.h, your above suggestion would result in declaring bindresvport/bindresvport_sa *only if* the user explicitely defines _BSD_SOURCE or _GNU_SOURCE on the command line. That's not feasible. The question is, why does libtirpc declare the functions at all? Does it come with its own implementation? Whether or not, I think the problem are the libtirpc headers in the first place. There's a similar case with krb5 headers, where gssrpc/rpc.h declares bindresvport as well, but that's fixed by the gssrpc/rename.h header, which is included automatically by gssrpc/rpc.h via gssrpc/types.h: #define bindresvport gssrpc_bindresvport However, given that on Linux the declarations are available by default, you will see the same warnings when using libtirpc's rpc/rpc.h header in conjunction with netinet/in.h. I just tested it on Fedora 13: $ gcc -c -I/usr/include/tirpc -Wredundant-decls x.c In file included from x.c:3: /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of ‘bindresvport’ /usr/include/netinet/in.h:440: note: previous declaration of ‘bindresvport’ was here But note that this only occurs with -Wredundant-decls, which is not one of the default warnings. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On Aug 21 10:54, Corinna Vinschen wrote: On Aug 20 21:07, Charles Wilson wrote: #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE) This is not the right solution. [...] On Linux, bindresvport and bindresvport6 are available by default, [...] Well, the declaration of bindresvport6 is available, the function is just not defined in any lib, apparently. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 08/19/2010 11:13 AM, Charles Wilson wrote: libtirpc is an updated version of the Sun RPC library. As such, it replaces part of the (orphaned) sunrpc package -- just as on linux, it replaces the built-in RPC routines in glibc: http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php You should update sunrpc, if installed, to 4.0-4 or above. The headers are installed into /usr/lib/tirpc/rpc/* and not /usr/lib/rpc/ As a consequence, developers must add -I/usr/lib/tirpc when compiling RPC clients and servers on cygwin. Similarly, linking requires -ltirpc. However, this is the same procedure used on linux -- so any client that has already been taught how to accept tirpc on linux will be fine on cygwin. (Hmm - libvirt hasn't yet learned how to use tirpc on Linux, since rpc/rpc.h is directly in /usr/include on Fedora as part of glibc-headers; so I had to run 'make CFLAGS=-I/usr/include/tirpc LDFLAGS=-ltirpc', but that's an issue for the libvirt mailing list). Meanwhile, this warning is a bit annoying; and did not happen with the older sunrpc headers. Any chance you can silence them in a -2 release? In file included from ././remote/qemu_protocol.h:9, from remote/qemu_protocol.c:7: /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:21: warning: previous declaration of 'bindresvport' was here /usr/include/tirpc/rpc/rpc.h:95: warning: redundant redeclaration of 'bindresvport_sa' [-Wredundant-decls] /usr/include/netinet/in.h:22: warning: previous declaration of 'bindresvport_sa' was here But in spite of the warnings, I was still able to build libvirt on cygwin after today's upgrade, so good job on the release. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
On 8/20/2010 8:35 PM, Eric Blake wrote: (Hmm - libvirt hasn't yet learned how to use tirpc on Linux, since rpc/rpc.h is directly in /usr/include on Fedora as part of glibc-headers; so I had to run 'make CFLAGS=-I/usr/include/tirpc LDFLAGS=-ltirpc', but that's an issue for the libvirt mailing list). Meanwhile, this warning is a bit annoying; and did not happen with the older sunrpc headers. Any chance you can silence them in a -2 release? In file included from ././remote/qemu_protocol.h:9, from remote/qemu_protocol.c:7: /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of 'bindresvport' [-Wredundant-decls] /usr/include/netinet/in.h:21: warning: previous declaration of 'bindresvport' was here /usr/include/tirpc/rpc/rpc.h:95: warning: redundant redeclaration of 'bindresvport_sa' [-Wredundant-decls] /usr/include/netinet/in.h:22: warning: previous declaration of 'bindresvport_sa' was here Well, looking at linux, the declarations in netinet/in.h are guarded by #if defined __USE_MISC || defined __USE_GNU These symbols are activated in (linux's) features.h by: #if defined _BSD_SOURCE || defined _SVID_SOURCE # define __USE_MISC 1 #endif #ifdef _GNU_SOURCE # define __USE_GNU 1 #endif Given that the only *SOURCE flags supported by cygwin's headers are: _BSD_SOURCE _POSIX_SOURCE _XOPEN_SOURCE _GNU_SOURCE (and, the newlib headers don't employ the __USE_* indirection), I think the correct fix is to modify cygwin's netinet/in.h to add the following guard around the declaration of bindresvport and bindresvport_sa: #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE) If you concur, I'll post a patch to that effect to cygwin-patches (we use our own header, not newlib's, for netinet/in.h). -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1
libtirpc is an updated version of the Sun RPC library. As such, it replaces part of the (orphaned) sunrpc package -- just as on linux, it replaces the built-in RPC routines in glibc: http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php You should update sunrpc, if installed, to 4.0-4 or above. The headers are installed into /usr/lib/tirpc/rpc/* and not /usr/lib/rpc/ As a consequence, developers must add -I/usr/lib/tirpc when compiling RPC clients and servers on cygwin. Similarly, linking requires -ltirpc. However, this is the same procedure used on linux -- so any client that has already been taught how to accept tirpc on linux will be fine on cygwin. This version is compiled without the XDR routines, as cygwin-1.7.2+ provides those routines internally. It is compiled without AUTH_DES support (that is, cygwin libtirpc is not NIS-aware, because there is not yet any cygwin NIS server or client; since NIS requires a portmap or rpcbind implementation, we have a bit of a chicken/egg issue). Also, it is compiled without GSS_API support, because the official cygwin distribution does not yet contain any Kerboros implementation. Thus, this version of libtirpc supports only unencrypted communication. However, MOST uses of RPC are unencrypted, so this shouldn't be a big deal. Official PR blurb: -- This package contains SunLib's implementation of transport-independent RPC (TI-RPC) documentation. This library forms a piece of the base of Open Network Computing (ONC), and is derived directly from the Solaris 2.3 source. TI-RPC is an enhanced version of TS-RPC that requires the UNIX System V Transport Layer Interface (TLI) or an equivalent X/Open Transport Interface (XTI). TI-RPC is on-the-wire compatible with the TS-RPC, which is supported by almost 70 vendors on all major operating systems. TS-RPC source code (RPCSRC 4.0) remains available from several internet sites. -- Charles Wilson volunteer libtirpc maintainer for cygwin To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
