Re: [HACKERS] Python3.4 detection on 9.6 configuration

[Lou Picciano]

- Original Message -

> From: "Tom Lane"  
> To: "Lou Picciano"  
> Cc: pgsql-hackers@postgresql.org 
> Sent: Wednesday, September 28, 2016 9:33:06 AM 
> Subject: Re: [HACKERS] Python3.4 detection on 9.6 configuration 

> Lou Picciano  writes: 
> > Trying to build 9.6RC1, with Python3.4, on OpenIndiana (Illumos). It 
> > seems the detection of shared library status of the .so has changed. 

Specifically, configure is not finding the .so. It's not that the so isn't 
built 'shared'; it is. 

> Changed from what? I don't recall that we've touched that code in quite 
> some time. What was the last version that worked for you? What 
> exactly is failing? 

Core bit seems to be the python3.4-config behavior: 


/usr/bin/python3.4-config --extension-suffix 

.cpython-34m.so 
I don't know if this is designed behavior for Python3.4 - or if it's a bug 
there? I'm working this with the Python gang as well. 

Of course, this option doesn't exist under Python2.7. 

> I'm having a hard time following your not-really-a-patch, but it looks 
> like you're proposing forcing python_enable_shared=1 on Solaris, 

Certainly not! I was simply offering this as evidence that PostgreSQL will 
build just fine, against Python3.4, using this hack. (It's useful in getting us 
a working build in situ o continue other testing - even before the more elegant 
fix - whatever that turns out to be!) 

> which sounds like a pretty bad idea. AFAIK the shared-ness of libpython is 
> up to whoever built it. 

Indeed. As I mentioned, our Python3.4 is built shared. 

> regards, tom lane 

Re: [HACKERS] Python3.4 detection on 9.6 configuration

[Tom Lane]

Lou Picciano  writes:
> Trying to build 9.6RC1, with Python3.4, on OpenIndiana (Illumos). It
> seems the detection of shared library status of the .so has changed.

Changed from what?  I don't recall that we've touched that code in quite
some time.  What was the last version that worked for you?  What
exactly is failing?

I'm having a hard time following your not-really-a-patch, but it looks
like you're proposing forcing python_enable_shared=1 on Solaris, which
sounds like a pretty bad idea.  AFAIK the shared-ness of libpython is
up to whoever built it.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Python3.4 detection on 9.6 configuration

[Lou Picciano]

PostgreSQL Friends: 

Trying to build 9.6RC1, with Python3.4, on OpenIndiana (Illumos). It seems the 
detection of shared library status of the .so has changed. This appears to be 
related to a different(?) elucidation of python configuration. 

A 'hardwired' change to the configure script to trap platform 'solaris' will 
work, but this seems the inappropriate approach. 

Would be happy to work through this here - I'd like to make it a small 
'contribution'. 

Clipped from configure script: 



1. 
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking how to link an embedded 
Python application" >&5 

2. 
$as_echo_n "checking how to link an embedded Python application... " >&6; } 

3. 

4. 
python_libdir=`${PYTHON} -c "import distutils.sysconfig; print(' 
'.join(filter(None,distutils.sysconfig.get_config_vars('LIBDIR'"` 

5. 
python_ldlibrary=`${PYTHON} -c "import distutils.sysconfig; print(' 
'.join(filter(None,distutils.sysconfig.get_config_vars('LDLIBRARY'"` 

6. 
python_so=`${PYTHON} -c "import distutils.sysconfig; print(' 
'.join(filter(None,distutils.sysconfig.get_config_vars('SO'"` 

7. 
echo "-" 

8. 
echo "- LOU MOD: python_so: $python_so" 

9. 
echo "-" 

10. 

11. 
configure finds '.so' on Python2.7 

12. 
configure finds '.cpython-34m.so' on Python3.4 

13. 

14. 
- LATER in the config script, the following 'hardwired' change will 
'fix' this, but is likely not the right approach: 

15. 
(our Python _is_ built as a shared lib. So, this is wonky, but it will work: ) 

16. 

17. 
# We need libpython as a shared library. With Python >=2.5, we 

18. 
# check the Py_ENABLE_SHARED setting. On Debian, the setting is not 

19. 
# correct before the jessie release (http://bugs.debian.org/695979). 

20. 
# We also want to support older Python versions. So as a fallback 

21. 
# we see if there is a file that is named like a shared library. 

22. 

23. 
if test "$python_enable_shared" != 1; then 

24. 
if test "$PORTNAME" = darwin; then 

25. 
# macOS does supply a .dylib even though Py_ENABLE_SHARED does 

26. 
# not get set. The file detection logic below doesn't succeed 

27. 
# on older macOS versions, so make it explicit. 

28. 
python_enable_shared=1 

29. 
elif test "$PORTNAME" = win32; then 

30. 
# Windows also needs an explicit override. 

31. 
python_enable_shared=1 

32. 
# - MOD BY LOU:  

33. 
elif test "$PORTNAME" = solaris; then 

34. 
# Solaris explicit override. 

35. 
python_enable_shared=1 

36. 
else 

37. 
# We don't know the platform shared library extension here yet, 

38. 
# so we try some candidates. 

39. 
for dlsuffix in .so .sl; do 

40. 
if ls "$python_libdir"/libpython*${dlsuffix}* >/dev/null 2>&1; then 

41. 
python_enable_shared=1 

42. 
break 

43. 
fi 

44. 
done 

45. 
fi 

46. 
fi