Add dtrace variant to glib (RH7)#6968
Conversation
|
@luigi-calori tried this PR and it seems to work as expected, a simple sync with upstream is all you need to trigger Travis to run again (it was broken at the time of this PR). |
|
Can anybody check if this is also solved by #7157 ? |
| version('2.42.1', '89c4119e50e767d3532158605ee9121a') | ||
|
|
||
| variant('libmount', default=False, description='Build with libmount support') | ||
| variant('dtrace', default=True, description='Build with dtrace support') |
There was a problem hiding this comment.
Since glib+dtrace will fail if dtrace is present on the system, I think this should be disabled by default and enabled only when really needed. @alalazo @luigi-calori any thoughts?
There was a problem hiding this comment.
I have no idea of what dtrace is used for.
I have tried to stick as much as possible with previous behavior.
As it seems that dtrace is on by default, in glib, I set the default variant accordingly.
I' m currently trying to see if #7157 can be a substitute of this PR
There was a problem hiding this comment.
As far as I can see dtrace starts with:
#!/usr/bin/python
# vim: et sta sts=4 sw=4 ts=8
...At install time, if dtrace is present, we could put in path a "fake" dtrace that does:
#!/usr/env bash
python /usr/bin/dtraceso that the python used is consistent with what is in PYTHONHOME. Otherwise I think #7157 can't do much for a script that hardcodes which interpreter to use.
There was a problem hiding this comment.
@luigi-calori I generally agree with this:
I have tried to stick as much as possible with previous behavior.
...but in this case, default means broken by deafult :)
@alalazo Just like @luigi-calori I have no idea about what does dtrace support mean in glib. We can try this dtrace monkeypatching or leave it disabled (with some warning when +dtrace maybe), no preference at this point.
There was a problem hiding this comment.
There was a problem hiding this comment.
I think that the problem of setting PYTHONHOME to spack installed python ( happens when depending on python) can affect any package that rely on any python script that point
explicitly to system python
I have no idea why this variable is used but, in this particular case, where a build rely on a system provided python script, it seem to fix the issue.
It could happen with another script apart from dtrace, so disabling d
luigi-calori
force-pushed
the
pr/fix/glib_dtrace_pythonhome
branch
from
16926de to
c3341e1
Compare
4 participants
fix issue #6965 building glib on a system with dtrace installed (RH7)
The issue seem related to PYTHONHOME env var set on python dependent packages that
( on RH7 ) seem to prevent usage of system python scripts that, like dtrace are installed with sbang to
system python
It is a kind of workaround, would probably be better to provide a spack installation of dtrace