classification
Title: ctypes.util.find_library needlessly call crle on Solaris
Type: resource usage Stage: patch review
Components: ctypes Versions: Python 3.4, Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jbeck, jquast, martin.panter, swalker
Priority: normal Keywords: patch

Created on 2015-01-21 00:33 by jbeck, last changed 2017-01-28 22:41 by martin.panter.

Files
File name Uploaded Description Edit
crle-fix.patch jbeck, 2015-01-21 00:33
Messages (6)
msg234417 - (view) Author: John Beck (jbeck) Date: 2015-01-21 00:33
On Solaris, in Lib/ctypes/util.py, we have code that looks for
/usr/bin/crle and calls it to parse its output to try to determine
the Default Library Path.  This code broke recently (Solaris 12 build
65), as it expects to find a line starting with
    "Default Library Path (ELF):"
but the " (ELF)" part of that line was removed because it was no longer
needed.  So we need a change here regardless.  But it turns out that
calling crle is not needed at all because the default library path is
a constant on Solaris: "/lib/64:/usr/lib/64" in 64-bit mode and
"/lib:/usr/lib" in 32-bit mode.  Thus I offer the attached patch
for both 2.7 and 3.4.
msg247062 - (view) Author: Jeff Quast (jquast) * Date: 2015-07-21 20:48
John, What do you think of the patches attached to http://bugs.python.org/issue20664 ?

"crle is not needed at all because the default library path is
a constant on Solaris"

I don't believe this to be true, source? crle is absolutely needed to add additional library lookup paths on Solaris, did this recently change?

crle is most certainly especially in regards to zones: a zone is unable to modify any of the system library paths, it wouldn't be able to install any new libraries in those given paths (/usr/lib and /lib are often shared read-only by the global zone), and crle must be used to add a library path to a writable mountpoint, such as /usr/local/lib, and often /opt and other various deviations must occur to accommodate gnu tools, etc.
msg247067 - (view) Author: John Beck (jbeck) Date: 2015-07-21 21:19
First, there are two related but somewhat separate issues here.

Regarding the patches attached to http://bugs.python.org/issue20664
they seem fine.  In theory, they should not be needed, as though it
is true that dump(1) moved from /usr/ccs/bin to /usr/bin in Solaris
11, /usr/ccs/bin still exists as a sym-link to /usr/bin.  But the
patches are written in a cautious manner, so the Right Thing [tm]
should happen in all circumstances.

Regarding my assertion that 'the default library path is a constant
on Solaris: "/lib/64:/usr/lib/64" in 64-bit mode and "/lib:/usr/lib"
in 32-bit mode', I stand by that but will clarify what I meant by
"default".  What I meant was "this is what the system provides, though
users may customize as needed".

I hope that helps.  If not, I'm happy to continue the conversation.
msg247069 - (view) Author: Jeff Quast (jquast) * Date: 2015-07-21 21:22
I looked over the focus on "default" path, thank you for clarifying!

Sadly, I can't help you move either of these patches forward, best wishes!
msg286418 - (view) Author: Shawn (swalker) Date: 2017-01-28 19:23
Could we get someone to evaluate this please?
msg286420 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-01-28 22:41
Do you have an opinion of the proposal Shawn?

Judging by John’s “[the constant] is what the system provides, though
users may customize as needed”, it sounds like the patch is more than a bug fix. Will it also mean find_library() will no longer search customized library directories? I’m not familiar with Solaris, but it seems this may not be intended or desired.

Why is this bug marked as “resource usage”?
History
Date User Action Args
2017-01-28 22:41:17martin.pantersetnosy: + martin.panter

messages: + msg286420
stage: patch review
2017-01-28 19:23:15swalkersetnosy: + swalker
messages: + msg286418
2015-07-21 21:22:08jquastsetmessages: + msg247069
2015-07-21 21:19:24jbecksetmessages: + msg247067
2015-07-21 20:48:01jquastsetnosy: + jquast
messages: + msg247062
2015-01-21 00:33:02jbeckcreate