Date:   Fri, 22 Feb 2019 08:52:02 +0100
From:   Patrick Steinhardt <ps@pks.im>
To:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/3] configure.ac: more carefully detect availability of
 res_querydomain(3)
Message-ID: <20190222075202.GA13960@ncase>
References: <a6f2aaea93c1293e62d5109b10d47a7675a45393.1549290423.git.ps@pks.im>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn"
Content-Disposition: inline
In-Reply-To: <a6f2aaea93c1293e62d5109b10d47a7675a45393.1549290423.git.ps@pks.im>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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.
>=20
> 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

--x+6KMIRAuhnl3hBn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEtmscHsieVjl9VyNUEXxntp6r8SwFAlxvqiIACgkQEXxntp6r
8SwG/A/+P0Qn7LNjT6t/OLPud9K9Ff2Nig3781LulesvSvZX2BSYuhLCfP9dCZQ1
tH8WXx5dxivzPsQ2Wo2CgbwWoKeTNPhWk+fvLSt7i0S5PhM51dU3SShAtpWHYEm1
stB1sYJdlqexEzrBsOWBtWR9fbV2bJjnhmW9BXr9QV79XnbCgf2q6xWQMSvtvLrw
hbBdKK2LI6sXfKE3Us+vhfcYE9tE720usqnBuTiPsw6/EfTQXaHBqxgufKJONLyT
PcuwtyiDmsKbtI3gv4jfM5yE9glN6Fv/pSWIGfh7jLt8VyPaZ8+BFIAg20F5WSLT
g1SiAupHVBsYp8GwmGyG3+8m29OEK67egP+XCeMpA/yN5osIlf6oUUwJ38CFzSY/
QJFBkhR4qV1mKsuJLmofiZ+KEIXnH6b3lwFx2XVwAAYkGDqoXX4di4lBfOsC6pz4
DsnuVFLYETaGi9f5g4homnX5sIwr01NPEQ22R1S6YRz7mQWXFcwWeQmLNg8WZhAe
P1VmysxstgTpI6q9+E3Hcf4wwGGzQXir466EpnxnmRwzwC26oqkFFgFa/+8+s1Yj
Ot3VkUnrCL6DapiwKOvL2f11wFVw11m1XhNQqjOYy3WJbmHJZlpiWxC7jObT9SgD
GK7hJMMxi+1YaTnkPp4sgCFeftYebSMPqBrVN6BInHsttkgKwCY=
=3kDl
-----END PGP SIGNATURE-----

--x+6KMIRAuhnl3hBn--