Обсуждение: pgsql: Huh, we do need to look in $python_configdir for the Python shli
Huh, we do need to look in $python_configdir for the Python shlib. Debian does it that way, for no doubt what seems to them a good reason. Thanks to Aidan Van Dyk for confirmation. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/fc76259f5b8473dbd3d2009b0e4a267cf3a7e704 Modified Files -------------- config/python.m4 | 13 ++++++++----- configure | 3 ++- 2 files changed, 10 insertions(+), 6 deletions(-)
On 10/04/2016 04:38 PM, Tom Lane wrote: > Huh, we do need to look in $python_configdir for the Python shlib. > > Debian does it that way, for no doubt what seems to them a good reason. > Thanks to Aidan Van Dyk for confirmation. > > Looks like there are still problems on Windows/mingw and OpenBSD - see frogmouth and curculio on the buildfarm. Do we need to fall back on the old mechanism? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Looks like there are still problems on Windows/mingw and OpenBSD - see
> frogmouth and curculio on the buildfarm.
Yeah. I just sent you an offlist request to look into what's happening
on frogmouth, and I'm talking to curculio's owner as well.
> Do we need to fall back on the old mechanism?
I hope not. What is really going on here is that we're being pickier
about whether we understand where libpython is. It looks to me like
on the machines where it's failing now, it was only accidental that
it worked at all before. The fact that frogmouth was producing
checking how to link an embedded Python application... -L -lpython2.7
certainly doesn't leave a warm feeling --- how did the linker parse that?
regards, tom lane
I wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Looks like there are still problems on Windows/mingw and OpenBSD - see
>> frogmouth and curculio on the buildfarm.
> Yeah. I just sent you an offlist request to look into what's happening
> on frogmouth, and I'm talking to curculio's owner as well.
The answer on curculio seems to be that OpenBSD doesn't bother with
providing symlinks like libpython2.7.so -> libpython2.7.so.0.0.
They've evidently hacked the linker so that it will find such a shlib
even when told only "-lpython2.7". I can't say that I think that's
a good design --- what if there's more than one version installed? ---
but there you have it. (Thanks to Mikael Kjellstrom for assisting
with this investigation.)
This seems reasonably easy to fix by allowing the configure probe
to accept files that have the expected name plus some trailing junk.
I can't tell what to make of frogmouth's results from here. Awaiting
your input. If you're not sure what to check, it would be helpful
to see the results of
python -c "import distutils.sysconfig; print(distutils.sysconfig.get_config_vars())"
and to know exactly where libpython.dll is and what it's named.
regards, tom lane