[PATCH 1/3] configure.ac: more carefully detect availability of res_querydomain(3)

[PATCH 1/3] configure.ac: more carefully detect availability of res_querydomain(3)

[Patrick Steinhardt]

Since glibc 2.2, the function res_querydomain(3) is implemented as a
define to `__res_querydomain`. Due to this implementation detail, using
`AC_CHECK_LIB` with a symbol name of "res_querydomain" will cause a
linking failure and thus fail to detect its availability. This is why
right now, we try to detect availability of `__res_querydomain` instead.

Unfortunately, this may break on other platforms where there is no
`__res_querydomain` but only the function without leading underscores.
To fix this, we can perform another `AC_CHECK_LIB([resolv],
[res_querydomain], ...)` call in case where the other one was not found
and only raise an error if both symbols weren't found.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 configure.ac | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 4bf5aea..cb9d921 100644
--- a/configure.ac
+++ b/configure.ac
@@ -411,7 +411,8 @@ if test "$enable_gss" = yes; then
 fi
 
 dnl libdnsidmap specific checks
-AC_CHECK_LIB([resolv], [__res_querydomain], , AC_MSG_ERROR(res_querydomain needed))
+AC_CHECK_LIB([resolv], [__res_querydomain], ,
+	AC_CHECK_LIB([resolv], [res_querydomain], , AC_MSG_ERROR(res_querydomain needed)))
 
 AC_ARG_ENABLE([ldap],
 	[AS_HELP_STRING([--disable-ldap],[Disable support for LDAP @<:default=detect@:>@])])
-- 
2.20.1

[PATCH 2/3] file: fix missing include for PATH_MAX constant

[Patrick Steinhardt]

While making use of the PATH_MAX constant, "file.c" does not include the
"limits.h" header. While it is being transitively included via other
headers on most platforms, it is not on e.g. musl-based systems.

Add the include to fix compilation.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 support/misc/file.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/support/misc/file.c b/support/misc/file.c
index 4065376..e7c3819 100644
--- a/support/misc/file.c
+++ b/support/misc/file.c
@@ -27,6 +27,7 @@
 #include <dirent.h>
 #include <stdlib.h>
 #include <stdbool.h>
+#include <limits.h>
 
 #include "xlog.h"
 #include "misc.h"
-- 
2.20.1

Re: [PATCH 2/3] file: fix missing include for PATH_MAX constant

[Steve Dickson]

On 2/4/19 9:31 AM, Patrick Steinhardt wrote:
> While making use of the PATH_MAX constant, "file.c" does not include the
> "limits.h" header. While it is being transitively included via other
> headers on most platforms, it is not on e.g. musl-based systems.
> 
> Add the include to fix compilation.
Committed...

steved. 
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  support/misc/file.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/support/misc/file.c b/support/misc/file.c
> index 4065376..e7c3819 100644
> --- a/support/misc/file.c
> +++ b/support/misc/file.c
> @@ -27,6 +27,7 @@
>  #include <dirent.h>
>  #include <stdlib.h>
>  #include <stdbool.h>
> +#include <limits.h>
>  
>  #include "xlog.h"
>  #include "misc.h"
> 

[PATCH 3/3] svc_socket: fix use of undefined macro HAVE_GETRPCBYNUMBER_R

[Patrick Steinhardt]

The macro HAVE_GETRPCBYNUMBER_R is set based on whether the
`getrpcbynumber_r` function was found by autoconf or not. While another
location correctly checks whether it is set by using `#ifdef`,
`getservport()` instead wrongly uses `#if HAVE_GETRPCBYNUMBER_R`. This
may cause a compilation error with gcc with "-Werror=undef" if the macro
has not been defined.

Fix the error by using `#ifdef` instead.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 support/nfs/svc_socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/support/nfs/svc_socket.c b/support/nfs/svc_socket.c
index 1239712..d56507a 100644
--- a/support/nfs/svc_socket.c
+++ b/support/nfs/svc_socket.c
@@ -46,7 +46,7 @@ int getservport(u_long number, const char *proto)
 	struct rpcent *rpcp;
 	struct servent servbuf, *servp = NULL;
 	int ret = 0;
-#if HAVE_GETRPCBYNUMBER_R
+#ifdef HAVE_GETRPCBYNUMBER_R
 	char rpcdata[1024];
 	struct rpcent rpcbuf;
 
-- 
2.20.1

Re: [PATCH 3/3] svc_socket: fix use of undefined macro HAVE_GETRPCBYNUMBER_R

[Steve Dickson]

On 2/4/19 9:31 AM, Patrick Steinhardt wrote:
> The macro HAVE_GETRPCBYNUMBER_R is set based on whether the
> `getrpcbynumber_r` function was found by autoconf or not. While another
> location correctly checks whether it is set by using `#ifdef`,
> `getservport()` instead wrongly uses `#if HAVE_GETRPCBYNUMBER_R`. This
> may cause a compilation error with gcc with "-Werror=undef" if the macro
> has not been defined.
> 
> Fix the error by using `#ifdef` instead.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
Committed...

BTW... If the future, feel free to ping me it appears 
patches slide off my radar... like these did... ;-( 

steved.
> ---
>  support/nfs/svc_socket.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/support/nfs/svc_socket.c b/support/nfs/svc_socket.c
> index 1239712..d56507a 100644
> --- a/support/nfs/svc_socket.c
> +++ b/support/nfs/svc_socket.c
> @@ -46,7 +46,7 @@ int getservport(u_long number, const char *proto)
>  	struct rpcent *rpcp;
>  	struct servent servbuf, *servp = NULL;
>  	int ret = 0;
> -#if HAVE_GETRPCBYNUMBER_R
> +#ifdef HAVE_GETRPCBYNUMBER_R
>  	char rpcdata[1024];
>  	struct rpcent rpcbuf;
>  
> 

Re: [PATCH 3/3] svc_socket: fix use of undefined macro HAVE_GETRPCBYNUMBER_R

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Wed, Feb 27, 2019 at 12:16:18PM -0500, Steve Dickson wrote:
> 
> 
> On 2/4/19 9:31 AM, Patrick Steinhardt wrote:
> > The macro HAVE_GETRPCBYNUMBER_R is set based on whether the
> > `getrpcbynumber_r` function was found by autoconf or not. While another
> > location correctly checks whether it is set by using `#ifdef`,
> > `getservport()` instead wrongly uses `#if HAVE_GETRPCBYNUMBER_R`. This
> > may cause a compilation error with gcc with "-Werror=undef" if the macro
> > has not been defined.
> > 
> > Fix the error by using `#ifdef` instead.
> > 
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> Committed...
> 
> BTW... If the future, feel free to ping me it appears 
> patches slide off my radar... like these did... ;-( 
> 
> steved.

Will do. I know from my own experience that it's hard to keep
track and be able to always respond in time :)

So thanks for your review and for committing them.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/3] configure.ac: more carefully detect availability of res_querydomain(3)

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Mon, Feb 04, 2019 at 03:31:18PM +0100, Patrick Steinhardt wrote:
> Since glibc 2.2, the function res_querydomain(3) is implemented as a
> define to `__res_querydomain`. Due to this implementation detail, using
> `AC_CHECK_LIB` with a symbol name of "res_querydomain" will cause a
> linking failure and thus fail to detect its availability. This is why
> right now, we try to detect availability of `__res_querydomain` instead.
> 
> Unfortunately, this may break on other platforms where there is no
> `__res_querydomain` but only the function without leading underscores.
> To fix this, we can perform another `AC_CHECK_LIB([resolv],
> [res_querydomain], ...)` call in case where the other one was not found
> and only raise an error if both symbols weren't found.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>

Is there anything I can do to get this rolling and improve my
patches? Or did I accidentally pick the wrong mailing list for
the userspace part of nfs?

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/3] configure.ac: more carefully detect availability of res_querydomain(3)

[J. Bruce Fields]

On Fri, Feb 22, 2019 at 08:52:02AM +0100, Patrick Steinhardt wrote:
> On Mon, Feb 04, 2019 at 03:31:18PM +0100, Patrick Steinhardt wrote:
> > Since glibc 2.2, the function res_querydomain(3) is implemented as a
> > define to `__res_querydomain`. Due to this implementation detail, using
> > `AC_CHECK_LIB` with a symbol name of "res_querydomain" will cause a
> > linking failure and thus fail to detect its availability. This is why
> > right now, we try to detect availability of `__res_querydomain` instead.
> > 
> > Unfortunately, this may break on other platforms where there is no
> > `__res_querydomain` but only the function without leading underscores.
> > To fix this, we can perform another `AC_CHECK_LIB([resolv],
> > [res_querydomain], ...)` call in case where the other one was not found
> > and only raise an error if both symbols weren't found.
> > 
> > Signed-off-by: Patrick Steinhardt <ps@pks.im>
> 
> Is there anything I can do to get this rolling and improve my
> patches? Or did I accidentally pick the wrong mailing list for
> the userspace part of nfs?

This is the right mailing list.  Steve Dickson is the nfs-utils
maintainer, it's probably a good idea to include him directly as well,
sometimes people miss stuff on the list.

--b.

Re: [PATCH 1/3] configure.ac: more carefully detect availability of res_querydomain(3)

[Steve Dickson]

On 2/22/19 2:52 AM, Patrick Steinhardt wrote:
> On Mon, Feb 04, 2019 at 03:31:18PM +0100, Patrick Steinhardt wrote:
>> Since glibc 2.2, the function res_querydomain(3) is implemented as a
>> define to `__res_querydomain`. Due to this implementation detail, using
>> `AC_CHECK_LIB` with a symbol name of "res_querydomain" will cause a
>> linking failure and thus fail to detect its availability. This is why
>> right now, we try to detect availability of `__res_querydomain` instead.
>>
>> Unfortunately, this may break on other platforms where there is no
>> `__res_querydomain` but only the function without leading underscores.
>> To fix this, we can perform another `AC_CHECK_LIB([resolv],
>> [res_querydomain], ...)` call in case where the other one was not found
>> and only raise an error if both symbols weren't found.
>>
>> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> 
> Is there anything I can do to get this rolling and improve my
> patches? Or did I accidentally pick the wrong mailing list for
> the userspace part of nfs?
Sorry about this... I'm looking at them now... 

steved.

> 
> Patrick
> 

Re: [PATCH 1/3] configure.ac: more carefully detect availability of res_querydomain(3)

[Steve Dickson]

On 2/4/19 9:31 AM, Patrick Steinhardt wrote:
> Since glibc 2.2, the function res_querydomain(3) is implemented as a
> define to `__res_querydomain`. Due to this implementation detail, using
> `AC_CHECK_LIB` with a symbol name of "res_querydomain" will cause a
> linking failure and thus fail to detect its availability. This is why
> right now, we try to detect availability of `__res_querydomain` instead.
> 
> Unfortunately, this may break on other platforms where there is no
> `__res_querydomain` but only the function without leading underscores.
> To fix this, we can perform another `AC_CHECK_LIB([resolv],
> [res_querydomain], ...)` call in case where the other one was not found
> and only raise an error if both symbols weren't found.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
Committed...

steved.
> ---
>  configure.ac | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 4bf5aea..cb9d921 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -411,7 +411,8 @@ if test "$enable_gss" = yes; then
>  fi
>  
>  dnl libdnsidmap specific checks
> -AC_CHECK_LIB([resolv], [__res_querydomain], , AC_MSG_ERROR(res_querydomain needed))
> +AC_CHECK_LIB([resolv], [__res_querydomain], ,
> +	AC_CHECK_LIB([resolv], [res_querydomain], , AC_MSG_ERROR(res_querydomain needed)))
>  
>  AC_ARG_ENABLE([ldap],
>  	[AS_HELP_STRING([--disable-ldap],[Disable support for LDAP @<:default=detect@:>@])])
>