[Lldb-commits] [PATCH] D13625: Support RHEL 7 and similar systems that use architecture-specific Python lib dirs.

[Pavel Labath via lldb-commits]

labath added a comment.

In http://reviews.llvm.org/D13625#264862, @tfiala wrote:

> In http://reviews.llvm.org/D13625#264786, @labath wrote:
>
> > Could you submit the change with full context next time? It makes review much easier.
>
>
> Tell me the diff line you want.  I'm doing the same type of diffs I have submitted for years.  I'll adjust my process.


It depends on your process I guess. If you are generating the diff from svn, the command is `svn diff --diff-cmd "diff -x -U9999"`. If you are using arcanist to upload your diffs (which I recommend, btw :) ), it will do that for you.

> 

> 

> > I don't understand what are you trying to achieve completely, but it feels to me you are trying to solve the wrong side of the problem. If we are on a system which uses lib64 as the directory for it's libraries, then lldb libraries should go into the lib64 folder as well (by compiling with -DLLVM_LIBDIR_SUFFIX=64). If the directory still comes out wrong (or the libraries don't end up in lib64) then we should fix that. Could you try if -DLLVM_LIBDIR_SUFFIX=64 solves your problems first?

> 

> 

> Python's choice of desired lib dir is orthogonal to whatever else we want to do on a system.  The most precise way to handle that is to ask python to tell us where it wants its lib/module dirs placed.  If we go to a system where python (for whatever reason, including somebody who builds a custom python that does something else entirely) wants to put it in some entirely different lib configuration, this will handle it.  Going to a fixed directory to satisfy python's module directory, which itself can change based on build configuration, doesn't seem like a good idea.

> 

> This change asks python "where do you put your libs" on POSIX systems (Xcode build excluded).  And then lldb learns and responds to it.  I much prefer that to saying the lib directory for all of lldb must match whatever the python happens to be doing.

> 

> That's my take.


Ok. Is this some hypothetical scenario, or have you actually encountered a system where python uses e.g. lib64 and the rest of the system the opposite?

I understand your desires, but your approach e.g. makes cross-compiling impossible (or, at least assumes that target python uses the same directory as the build one (if the build machine even has python in the first place)). I'd like to avoid doing this if it is possible to work around it. Have you checked whether it is possible to extract this information from cmake, without running any code (perhaps parsing PYTHON_LIBRARIES or something).


http://reviews.llvm.org/D13625