This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Michael.Felt
Recipients David.Edelsohn, Michael.Felt, ericvw, pablogsal
Date 2019-07-29.10:22:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1564395761.85.0.362039078003.issue37690@roundup.psfhosted.org>
In-reply-to
Content
David gives several reasons why this PR should not be used.

And, in reading them - while I follow them at face value, there may be things I miss due to ignorance or being naive (more the system admin than tool developer).

Isn't there an configure --enable-shared that (sadly!) gives a SVR4 like shared library (sys-admin view - it is a .so file (libpython3.7m.so) rather than "the same file" as a member of an archive (e.g., libpython3.a[libpython3.7m.so]).

While it may be common on other OS systems to have two "lib" directories, e.g., /usr/lib and /usr/lib64 - on AIX there is expected - one directory (/usr/lib) and the "archives aka .a files" may have multiple members, e.g., a 32-bit and a 64-bit member.

Not using .a files makes it very hard to keep a "tight-ship" on an AIX server - and I feel it is incorrect for a tool to dictate system administration policy.

As I do not know how Python looks on other systems - here is a short view of Python and ldd when --enable-shared is used:

/opt/bin/python3 needs:
         /usr/lib/libc.a(shr.o)
         /usr/lib/libpthreads.a(shr_xpg5.o)
         /opt/lib/libpython3.7m.so
         /unix
         /usr/lib/libcrypt.a(shr.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /usr/lib/libdl.a(shr.o)


Here is an example not using --enable-shared:
/opt/bin/python3 needs:
         /usr/lib/libc.a(shr.o)
         /usr/lib/libpthreads.a(shr_xpg5.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /usr/lib/libdl.a(shr.o)
         /usr/lib/libintl.a(libintl.so.8)
         /unix
         /usr/lib/libcrypt.a(shr.o)
         /usr/lib/libpthread.a(shr_xpg5.o)
         /usr/lib/libiconv.a(libiconv.so.2)
         /usr/lib/libc.a(shr_64.o)
         /usr/lib/libcrypt.a(shr_64.o)

Both versions build ".so" files, that are accessed using dlopen()

root@x066:[/home/root]find /opt/lib/python3.7 -name \*.so | head
/opt/lib/python3.7/lib-dynload/_asyncio.so
/opt/lib/python3.7/lib-dynload/_bisect.so
/opt/lib/python3.7/lib-dynload/_blake2.so
/opt/lib/python3.7/lib-dynload/_bz2.so
/opt/lib/python3.7/lib-dynload/_codecs_cn.so
/opt/lib/python3.7/lib-dynload/_codecs_hk.so
/opt/lib/python3.7/lib-dynload/_codecs_iso2022.so
/opt/lib/python3.7/lib-dynload/_codecs_jp.so
/opt/lib/python3.7/lib-dynload/_codecs_kr.so
/opt/lib/python3.7/lib-dynload/_codecs_tw.so

and

root@x064:[/opt/lib/python3.7]find /opt/lib/python3.7 -name \*.so | head
/opt/lib/python3.7/lib-dynload/_asyncio.so
/opt/lib/python3.7/lib-dynload/_bisect.so
/opt/lib/python3.7/lib-dynload/_blake2.so
/opt/lib/python3.7/lib-dynload/_bz2.so
/opt/lib/python3.7/lib-dynload/_codecs_cn.so
/opt/lib/python3.7/lib-dynload/_codecs_hk.so
/opt/lib/python3.7/lib-dynload/_codecs_iso2022.so
/opt/lib/python3.7/lib-dynload/_codecs_jp.so
/opt/lib/python3.7/lib-dynload/_codecs_kr.so
/opt/lib/python3.7/lib-dynload/_codecs_tw.so

Lastly, The PR, asis, appears to be broken.

make: *** [Makefile:613: sharedmods] Illegal instruction (core dumped)
/opt/bin/make returned an error
root@x066:[/data/prj/python/python3-3.9]make V=1
 CC='xlc_r' LDSHARED='xlc_r -G    ' OPT='-DNDEBUG -O'   _TCLTK_INCLUDES='' _TCLTK_LIBS=''       ./python -E ../git/python3-3.9/setup.py  build
make: *** [Makefile:613: sharedmods] Illegal instruction (core dumped)

Note also: LDSHARED has added xlc_r to it's flags - that does not seem right either.

-1
History
Date User Action Args
2019-07-29 10:22:41Michael.Feltsetrecipients: + Michael.Felt, ericvw, David.Edelsohn, pablogsal
2019-07-29 10:22:41Michael.Feltsetmessageid: <1564395761.85.0.362039078003.issue37690@roundup.psfhosted.org>
2019-07-29 10:22:41Michael.Feltlinkissue37690 messages
2019-07-29 10:22:41Michael.Feltcreate