Hi, On 06.02.19 23:31, Knut Petersen wrote:
On 06.02.19 15:09, Werner LEMBERG wrote:That leaves the two problems of- LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so (I rm'ed LLVMgold.so there for the purpose of the above gub run.)This is definitely *not* a gub issue. It's strange that only the compilation of guile is affected by the problem, but I consider this a pure coincidence. IOW, this should be added to the gub documentation, as a special preparation step for some LLVM/binutils combinations.I agree.
I have no idea regarding that issue and trust your assessment.
Use /usr/bin/env python2? Does every python 2.x installation really contain a python2 executable?- the need to make sure that `python` calls a python2 interpreter.No idea how this could be solved elegantly. I guess it can't, so we have again something to document...
Not sure, but according to PEP 394, they "should". The PEP dates back to 2011, so I'd assume that all systems have a corresponding alias by now, and only the default `python` is different.
(IIUC, Gentoo follows Arch's example, see the bottom of https://wiki.gentoo.org/wiki/Python; do we have any Gentoo users here?)
Of course, Arch obviously disregards the PEP's first recommendation (python should point to python2), so it's perfectly fair to consider this entirely Arch's / Gentoo's fault. However, one of the good reasons Archers state to follow the explicit python2 / python3 spelling (and having python3 as default) is that python2 will see it's end of maintenance at the end of this year, and they plan to stop distributing python2 as a first-class citizen in the core repositories more or less immediately (it will still be easily available via community repos though). So following all of the PEP, you'd end up with a system that has python3, but neither python nor python2. Perhaps that's harsh, but it's a reasonable decision given that official support ends.
In the rationale, the PEP says"As some of the former distributions did not provide a python2 command by default, there was previously no way for Python 2 code (or any code that invokes the Python 2 interpreter directly rather than via sys.executable) to reliably run on all Unix-like systems without modification, as the python command would invoke the wrong interpreter version on some systems, and the python2 command would fail completely on others."
so this might not be *entirely* smooth.https://mail.python.org/pipermail/python-dev/2011-March/108491.html mentions Debian, Slack and BSDs; but AFAIK, all of those follow the PEP these days.
I think we also would need to change some lilypond files ...
FWIW, this is what is done in the Arch packaging process:
for file in $(find . -name '*.py' -print); do
sed -i 's_^#!.*/usr/bin/python_#!/usr/bin/python2_' $file
sed -i 's_^#!.*/usr/bin/env.*python_#!/usr/bin/env python2_' $file
done
sed -i 's|GUILE_CFLAGS=.*|GUILE_CFLAGS="`pkg-config --cflags
guile-1.8`"|' configure
sed -i 's|GUILE_LDFLAGS=.*|GUILE_LDFLAGS="`pkg-config --libs
guile-1.8`"|' configure
plus a patch regarding fontsizes; not sure what this is about: https://git.archlinux.org/svntogit/community.git/tree/trunk/lilyfontsize.patch?h=packages/lilypondIt might be worth testing whether applying this patch upstream breaks anything for someone else; but of course, that's from an Arch user's perspective...
Cheers, Alex
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
