Re: BUG #6633: PL/Python build does not honor PYTHON on Mac OS X
От | Clay McClure |
---|---|
Тема | Re: BUG #6633: PL/Python build does not honor PYTHON on Mac OS X |
Дата | |
Msg-id | CAOVqfW-=coQSFtFFkr4FJ_8UrpA=UhDDHHma7r=5fg1JgjBxnA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6633: PL/Python build does not honor PYTHON on Mac OS X (Clay McClure <clay@daemons.net>) |
Ответы |
Re: BUG #6633: PL/Python build does not honor PYTHON on Mac
OS X
|
Список | pgsql-bugs |
On Tue, May 8, 2012 at 11:07 AM, Clay McClure <clay@daemons.net> wrote: > Thanks for your reply, Tom. I will check with the Homebrew > maintainers, but my (albeit limited) understanding of the subject is > that a framework Python is only needed for GUI applications. Unless > PL/Python is opening windows and drawing buttons, plpython.so should > work when linked against a non-framework python, whose libraries can > be found like so: > > =A0$ python-config --libs > > What is interesting to me is that the top-level configure script in > the Postgres source distribution already does this, saving the result > in `python_libspec`. It's not clear to me why that is later overridden > in the plpython Makefile to build against a framework python. > > I'll write back when I hear from the Homebrew folks. It turns out that `python-config --libs` is only useful when you're dealing with a unix-style (not framework) python. Since Mac OS X ships with framework pythons, it makes sense that PostgreSQL would assume a framework python, but it would be nice if it would also accomodate unix-style pythons. According to the Homebrew folks, here's how to do that: "The gist of it is to grab python-config --prefix and store it in a variable, say py_prefix. If the file $py_prefix/Python exists, you are dealing with a Framework build and -framework Python is the appropriate method of linking. Otherwise, you have a UNIX-style build and -lpython is the appropriate method of linking." The '-lpython' specifics are those reported by `python-config --libs`. Cheers, Clay
В списке pgsql-bugs по дате отправления: