Issues cross-compiling libpq 14.x to MacOS armv8

Vincas Dargis <vindrg@gmail.com> writes:

checking which random number source to use... /dev/urandom
checking for /dev/urandom...
configure: error: cannot check for file existence when cross compiling

Hmm ... this evidently stems from 16f96c74d.

AFAICS this is the only test in our configure script that is a hard
fail when cross-compiling, and I don't see a reason for it to be that.
We could just assume that /dev/urandom will be available --- that's no
worse than a lot of the other optimistic assumptions that configure
makes in that mode.

regards, tom lane

On 30 Nov 2021, at 20:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Vincas Dargis <vindrg@gmail.com> writes:

checking which random number source to use... /dev/urandom
checking for /dev/urandom...
configure: error: cannot check for file existence when cross compiling

Hmm ... this evidently stems from 16f96c74d.

AFAICS this is the only test in our configure script that is a hard
fail when cross-compiling, and I don't see a reason for it to be that.
We could just assume that /dev/urandom will be available --- that's no
worse than a lot of the other optimistic assumptions that configure
makes in that mode.

Agreed, I don't see a problem with that. I'm not terribly familiar with
supporting cross compilation in autoconf, would a reasonable approach be to
just remove the check altogether like the below sketch?

diff --git a/configure.ac b/configure.ac
index a5c10b8d56..80fe0de38d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2289,13 +2289,6 @@ elif test x"$PORTNAME" = x"win32" ; then
   AC_MSG_RESULT([Windows native])
 else
   AC_MSG_RESULT([/dev/urandom])
-  AC_CHECK_FILE([/dev/urandom], [], [])
-
-  if test x"$ac_cv_file__dev_urandom" = x"no" ; then
-    AC_MSG_ERROR([
-no source of strong random numbers was found
-PostgreSQL can use OpenSSL, native Windows API or /dev/urandom as a source of random numbers.])
-  fi
 fi

--
Daniel Gustafsson https://vmware.com/

Daniel Gustafsson <daniel@yesql.se> writes:

On 30 Nov 2021, at 20:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
AFAICS this is the only test in our configure script that is a hard
fail when cross-compiling, and I don't see a reason for it to be that.
We could just assume that /dev/urandom will be available --- that's no
worse than a lot of the other optimistic assumptions that configure
makes in that mode.

Agreed, I don't see a problem with that. I'm not terribly familiar with
supporting cross compilation in autoconf, would a reasonable approach be to
just remove the check altogether like the below sketch?

It seems like a useful test when *not* cross compiling, which is most
of the time. I'd just wrap that bit in

if test "$cross_compiling" = no; then
...
fi

(I'm a bit surprised that the AC_CHECK_FILE macro doesn't provide
an action-if-cross-compiling option, but it apparently doesn't.)

regards, tom lane

I wrote:

It seems like a useful test when *not* cross compiling, which is most
of the time. I'd just wrap that bit in
if test "$cross_compiling" = no; then

Or actually, since we should print something, it looks like this will do:

diff --git a/configure.ac b/configure.ac
index a5c10b8d56..7257afda20 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2287,6 +2287,8 @@ if test x"$with_ssl" = x"openssl" ; then
   AC_MSG_RESULT([OpenSSL])
 elif test x"$PORTNAME" = x"win32" ; then
   AC_MSG_RESULT([Windows native])
+elif test x"$cross_compiling" = x"yes"; then
+  AC_MSG_RESULT([assuming /dev/urandom])
 else
   AC_MSG_RESULT([/dev/urandom])
   AC_CHECK_FILE([/dev/urandom], [], [])

Off to see if I can verify that before pushing.

regards, tom lane

On 30 Nov 2021, at 22:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I wrote:

It seems like a useful test when *not* cross compiling, which is most
of the time. I'd just wrap that bit in
if test "$cross_compiling" = no; then

Or actually, since we should print something, it looks like this will do:

+1, looks reasonable.

+elif test x"$cross_compiling" = x"yes"; then

I noticed that we test without the x"foo" = x"yes" construction for zic (line
1135), should we change that while at it and be consistent for all
$cross_compiling uses?

--
Daniel Gustafsson https://vmware.com/

Daniel Gustafsson <daniel@yesql.se> writes:

I noticed that we test without the x"foo" = x"yes" construction for zic (line
1135), should we change that while at it and be consistent for all
$cross_compiling uses?

Probably. $cross_compiling should theoretically always be set, but
there's no harm in being bulletproof.

I had thought I could crank up a cross-compile test painlessly, but
at least on my available systems it doesn't seem to be painless :-(.
So I'm just going to push the change without having really tested
that end of it. I wonder if it is at all feasible to maintain a
cross-compiling buildfarm member ...

regards, tom lane

On 30.11.21 22:04, Tom Lane wrote:

Daniel Gustafsson <daniel@yesql.se> writes:

On 30 Nov 2021, at 20:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
AFAICS this is the only test in our configure script that is a hard
fail when cross-compiling, and I don't see a reason for it to be that.
We could just assume that /dev/urandom will be available --- that's no
worse than a lot of the other optimistic assumptions that configure
makes in that mode.

Agreed, I don't see a problem with that. I'm not terribly familiar with
supporting cross compilation in autoconf, would a reasonable approach be to
just remove the check altogether like the below sketch?

It seems like a useful test when *not* cross compiling, which is most
of the time.

You still don't know whether the file will exist on the system you are
running this on.

(I'm a bit surprised that the AC_CHECK_FILE macro doesn't provide
an action-if-cross-compiling option, but it apparently doesn't.)

Because you are only supposed to look for files that you need during the
build.

On 1 Dec 2021, at 07:11, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
On 30.11.21 22:04, Tom Lane wrote:

(I'm a bit surprised that the AC_CHECK_FILE macro doesn't provide
an action-if-cross-compiling option, but it apparently doesn't.)

Because you are only supposed to look for files that you need during the build.

So by that logic, do you think the AC_CHECK_FILE call should be removed?

--
Daniel Gustafsson https://vmware.com/

Daniel Gustafsson <daniel@yesql.se> writes:

On 1 Dec 2021, at 07:11, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
Because you are only supposed to look for files that you need during the build.

So by that logic, do you think the AC_CHECK_FILE call should be removed?

I don't buy that. The test is useful on net, and I don't particularly
believe that /dev/urandom will be there on one instance of a platform
and not another.

regards, tom lane

Thanks Tom!

Should we expect this fix in the next 14 patch release, or only in 15.x?

If latter, I would add this patch into Conan package itself, to make it work earlier.

Vincas Dargis <vindrg@gmail.com> writes:

Should we expect this fix in the next 14 patch release, or only in 15.x?

I did push it into v14:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=175edafd1f30a78643359b56c5545b5e7aabfb50

regards, tom lane