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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
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
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 <[email protected]>
>
> 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.
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 <[email protected]>
>
> 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
>
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 <[email protected]>
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@:>@])])
>
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 <[email protected]>
> ---
> 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"
>
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 <[email protected]>
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;
>
>
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 <[email protected]>
> 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