title: python 3.6 installation and lib64
body: <p>I'm trying to install the new Python (3.6, released just a few weeks back) from source on openSUSE 42.2. Everything</p>
  
  <pre><code>./configure --prefix /home/paul/2017 --enable-optimizations
  make
  make install
  </code></pre>
  
  <p>appears to work just fine, but when I call the shiny new interpreter I get this error:</p>
  
  <pre><code>Python 3.6.0 (default, Jan  9 2017, 22:01:27)                                                                                                                                     
  [GCC 4.8.5] on linux                                                                                                                                                              
  Type "help", "copyright", "credits" or "license" for more information.                                                                                                            
  Traceback (most recent call last):
    File "/home/paul/.pythonrc", line 7, in &lt;module&gt;
      import readline
  ModuleNotFoundError: No module named 'readline'
  </code></pre>
  
  <p>Now, the module is there, it is installed under $PREFIX/lib64/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so.
  Only the interpreter is not looking there (it is completely ignoring lib64, I checked with -vv).</p>
  
  <p>Update: To be clear, this does not only affect readline but everything under lib64, most notably the modules under lib-dynload.</p>
  
  <p>This appears to be a known issue, see <a href="http://bugs.python.org/issue1294959" rel="nofollow noreferrer">the Python bugtracker</a>. It's a fairly lengthy exchange ending in</p>
  
  <blockquote>
    <p>Is there agreement on what needs doing here?  I'd like to see this into 3.5 before it reaches its 10th birthday :)</p>
  </blockquote>
  
  <p>This leaves me a bit confused. Is this supposed to be resolved?
  I do not remember ever running into this issue before, so I wonder if it is a 3.6 regression.</p>
  
  <p>And obviously, any fix would be most welcome.</p>
  
  <p>Update: for the time being I can work around the issue by symlinking everything under lib64 into lib. Obviously, that is not an ideal solution; at the very least it defeats the purpose of introducing lib64 (being able to have 32 and 64 bit versions side-by-side) in the first place.
  I'd much prefer something in a config file.</p>