Re: Misidentification of Python shared library - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Misidentification of Python shared library
Date
Msg-id 7921.1475595951@sss.pgh.pa.us
Whole thread Raw
In response to Re: Misidentification of Python shared library  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Misidentification of Python shared library
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 10/04/2016 10:43 AM, Tom Lane wrote:
>> In short: I propose replacing all of this logic with "if there's something
>> in $python_libdir that has the right name to be a python shared library,
>> use that, else try the same in $python_configdir, else fail".  Thoughts?

> Seems reasonable.

Actually, given that we no longer support Python < 2.3, I am not sure
we need to bother with looking in $python_configdir at all.

But looking at the installations on my older Apple boxes, it seems that
*neither* $python_libdir nor $python_configdir contain any library at all;
rather libpython.dylib sits in good old /usr/lib and is found there
despite the -L switch pointing to noplace useful.  So I'm now thinking
that we should do the above dance in a list of directories like
"$python_libdir /usr/lib64 /usr/lib" (too bad there's no easy
platform-independent way to find out the linker's default search path).
We can add $python_configdir to that if it proves necessary, but I'll try
it without first.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kirill Berezin
Date:
Subject: Re: Proposal: ON UPDATE REMOVE foreign key action
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.