From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Misidentification of Python shared library |
Date: | 2016-10-04 15:07:36 |
Message-ID: | b0f76751-9c5f-fea6-7d0b-1d8fed13435a@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/04/2016 10:43 AM, Tom Lane wrote:
> While chasing down last night's failure on buildfarm member longfin,
> I came across an interesting factoid. If you just do
>
> ./configure --enable-shared
> make
> make install
>
> in unmodified Python sources, what you will get is an install tree in
> which libpython.so (or local equivalent such as .dylib) is installed
> in /usr/local/lib, while libpython.a is installed in a directory named
> like /usr/local/lib/python3.5/config-3.5m. I've verified this behavior
> on both Linux and macOS.
Wow, these modules have uncovered a number of cans of worms.
>
>
> 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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-10-04 15:12:28 | Re: pgsql: Extend framework from commit 53be0b1ad to report latch waits. |
Previous Message | Robert Haas | 2016-10-04 15:02:22 | pgsql: Extend framework from commit 53be0b1ad to report latch waits. |