On Thu, Aug 18, 2011 at 5:25 PM, Peter Eisentraut <pete...@gmx.net> wrote:
> On tor, 2011-08-18 at 14:51 +0530, Ashesh Vashi wrote: > > Please ignore the previous patch. > > Please find the updated patch. > > Committed more or less like that. > Thanks > > In passing I also fixed the build with Python 3 on Windows, which > apparently never worked before. But I suppose you have been referring > to the ActiveState Linux build all along. > Yes. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com/> *http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi> > > > > > -- > > > > Thanks & Regards, > > > > Ashesh Vashi > > EnterpriseDB INDIA: Enterprise PostgreSQL Company< > http://www.enterprisedb.com> > > > > > > > > *http://www.linkedin.com/in/asheshvashi*< > http://www.linkedin.com/in/asheshvashi> > > > > > > > > On Thu, Aug 18, 2011 at 12:57 PM, Ashesh Vashi < > > ashesh.va...@enterprisedb.com> wrote: > > > > > On Thu, Aug 18, 2011 at 1:25 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > > >> Peter Eisentraut <pete...@gmx.net> writes: > > >> > On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote: > > >> >> It's not immediately apparent to me why we should think that > > >> >> get_python_lib is less trustworthy than LIBPL; but if someone > > >> >> can make that case, I don't have any objection to this part of > > >> >> the patch. > > >> > > >> > The issue, at least for me, is that the file isn't necessarily > called > > >> > 'config' anymore. I have > > >> > /usr/lib/python3.2/config-3.2mu > > >> > > > One of the reason, I say that - we do have hard-coded values for the > config > > > directory. > > > Hence, I used the LIBPL. > > > > > >> > > >> Ah, I see. > > >> > > >> > LIBPL exists at least as far back as Python 2.2, so its use should > be > > >> > safe. > > >> > > >> Yeah, that part of the patch seems sane then. > > >> > > >> > Yes, because get_config_vars('LDVERSION') doesn't exist in that > version. > > >> > In theory, it would return '2.7', so everything would fit back > together, > > >> > but LDVERSION doesn't exist before 3.2. > > >> > > > Oops - sorry... > > > I did not know about it.. > > > > > >> > > >> Could we have the code use 'LDVERSION' if it gets a nonempty result, > > >> and otherwise fall back to the current scheme? But I guess first we > > >> need some details as to why the current scheme isn't sufficient. > > >> > > > Please find the attached patch as you suggested. > > > > > > Reason: > > > - As per my findings, ActiveState Python 3.2 does not provide shared > > > libraries along with it. > > > (Though - I am not sure about the earlier version of ActiveState > Python) > > > We can confirm the same using the following command: > > > ${PYTHON} -c "import distutils.sysconfig,string; > > > print(distutils.sysconfig.get_config_vars('Py_ENABLE_SHARED'))" > > > Which returns in this case '0'. > > > > > > And, getting values for the 'python_ldlibrary' and 'python_so' are > > > 'libpython3.2m.a' and '.cpython-32m.so' respectively. > > > So, the condition - *x"${python_ldlibrary}" != x"${ldlibrary}"* is > always > > > failing, and switching it back to link the old way. > > > > > > -- > > > > > > Thanks & Regards, > > > > > > Ashesh Vashi > > > EnterpriseDB INDIA: Enterprise PostgreSQL Company< > http://www.enterprisedb.com/> > > > > > > > > > > > > *http://www.linkedin.com/in/asheshvashi*< > http://www.linkedin.com/in/asheshvashi> > > > > > > > > >> > > >> regards, tom lane > > >> > > > > > > > > > >