Help? Unexpected PostgreSQL compilation failure using generic compile script - Mailing list pgsql-general

Hello.

For reasons I won't bore you with, we compile PostgreSQL from source 
rather than use the standard packages for some of our databases.

We've compiled numerous PostgreSQL versions, from 11.1 to 14.4, using a 
fairly generic and not particularly complicated compile script that has 
worked successfully on dozens (possibly hundreds, I don't keep track :) 
)  of redhat boxes using numerous different versions of RHEL.

This script has worked without incident for *years*. Until last week, 
where we tried to compile PostgreSQL 12.9 on an RHEL 7.9 box, where it 
bombed out with an error we have never seen before.

To be honest, I'm not sure what's going wrong. I am by no means a Linux 
sysadm or compile expert. I just run the script (and a variety of other 
post-build steps ...)

Our basic process:

1. Install pre-requisite libraries/packages:

yum install pam-devel
yum install libxml2-devel
yum install libxslt-devel
yum install openldap
yum install openldap-devel
yum install uuid-devel
yum install readline-devel
yum install openssl-devel
yum install libicu-devel
yum install uuid-devel
yum install gcc
yum install make

2. Create a user to compile the source and own the software. For 
example, pgbuild

3. Build a couple of directories owned by the build user for the 
destination, source, etc. We then run the following script under the 
build user.

targetdir={directory to install postgresql into}
sourcedir={directory where the postgresql unzipped and untarred tarball 
has been located}
builddir={temporary build directory}
port={port number}

rm -Rf ${targetdir}
rm -Rf ${builddir}
mkdir ${targetdir}
mkdir ${builddir}
cd ${builddir}

${sourcedir}/configure --prefix=${targetdir} --with-pgport=${port} \
                        --with-openssl \
                        --with-ldap \
                        --with-pam \
                        --with-icu \
                        --with-libxml \
                        --with-ossp-uuid \
                        --with-libxslt \
                        --with-libedit-preferred \
                        --with-gssapi \
                        --enable-debug
rc=$?
if [ $rc -ne 0 ]
then
echo "#### ERROR! Configure returned non-zero code $rc - press RETURN to 
continue / Ctrl+C to abort"
read ok
fi

make world
rc=$?
if [ $rc -ne 0 ]
then
echo "#### ERROR! make world returned non-zero code $rc - press RETURN 
to continue / Ctrl+C to abort"
read ok
fi

make check
rc=$?
if [ $rc -ne 0 ]
then
echo "#### ERROR! make check returned non-zero code $rc - press RETURN 
to continue / Ctrl+C to abort"
read ok
fi

make install-world
rc=$?
if [ $rc -ne 0 ]
then
echo "#### ERROR! install-world returned non-zero code $rc - press 
RETURN to continue / Ctrl+C to abort"
read ok
fi


So, pretty straightforward stuff. Run configure, make world, make check, 
make install-word and a little bit of basic error checking after each step.

For years we've been able to run this script without issue, until last 
week where the configure failed with the following error on one of our 
servers. After the usual hundreds of lines of text configure output the 
following:

   checking for library containing gss_init_sec_context... no

   configure: error: could not find function 'gss_init_sec_context' 
required for GSSAPI

And then bombed out with rc 1. Rest of the script aborted due to our 
error checking.


Bit odd, nothing we've seen before on dozens/numerous other compiles 
across the enterprise.

Then I spotted that our libraries pre-install doesn't include anything 
for GSSAPI. Bit of a bug in our pre-reqs step, perhaps we've got away 
with it previously and this one server in our whole estate doesn't have 
GSSAPI. I need to figure out how to install GSSAPI, but that's a bit of 
a faff and I need to get this build tested in a hurry.

So I simply removed the --with-gssapi, and tried again.

AND IT FAILED AGAIN.

This time it failed claiming it couldn't find the ldap library. Which is 
most -definitely- present.

I have no idea what's going on at this point. We have *never* had any 
issues like this. This script/process has been in place for years and 
we've never had any issues with it.

It gets weirder.

The compile step and make world steps work perfectly if the script is 
run under root. Though, of course, the make check step fails. Running it 
under root was inadvertent, but the fact the compile and make steps 
seemed to have run successfully was a bit of a surprise.


So a fairly basic script that has been used for years suddenly fails on 
a fairly generic RHEL 7.9 server.

I am no compilation expert. Obviously. Have I mised something basic? As 
I said, we've not seen problems like this before. Could there be some 
sort of issue on the box's configuration? If it works for root but not 
our usual build user could there be a user config with our account? Can 
anyone offer any insight on what I need to check? At the moment it all 
seems somewhat ... mystifying.

I am assuming there must be something wrong with the box/our 
configuration somewhere, but where to look? If anyone can help - even if 
it's to tell me I'm an idiot for missing one or more incredibly basic 
things somehow - I would be very grateful.

Many thanks.

Regards,

M.

-- 
Martin Goodson.

"Have you thought up some clever plan, Doctor?"
"Yes, Jamie, I believe I have."
"What're you going to do?"
"Bung a rock at it."