[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538
bapt added the comment: Per POSIX, the C locale is only expected to be ASCII. C.UTF-8 is a linux only thing (actually I thought it was a debian only thing, but maybe not). I was thinking about creating a C.utf8 locale on FreeBSD but it is not that simple to do (still doable and an interesting idea). Note that if it fails here, it is probably due also failing on other OS. At minimum: Dragonfly and Illumos for sure, maybe NetBSD and OpenBSD as well. haypo, do not hesitate to ping me on irc as usual if you want to discuss the issue. -- nosy: +bapt ___ Python tracker <http://bugs.python.org/issue30647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30647] CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP 538
bapt added the comment: More details here: C.UTF-8 is a glibc only thing: https://sourceware.org/glibc/wiki/Proposals/C.UTF-8 not even mainstream. The closest thing to a C locale with unicode would be to set everything to locale C but LC_CTYPE which would be set to en_US.UTF-8. The problem is if your data for ctype comes from CLDR they are different per locales. On FreeBSD, Dragonfly and Illumos, we have extected it so LC_CTYPE is the same on all locales. -- ___ Python tracker <http://bugs.python.org/issue30647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32597] Bad detection of clang
New submission from bapt : When building modules and trying to set the proper linker flags for the library runtime path, the detection of the compiler is wrong. the issue: https://bugs.python.org/issue20767 was showing the issue and imho badly fixed. Clang behave like gcc regarding how it passes flags to the linker: -Wl,... so clang and gcc should be treated exactly the same way and no specific code should be added for FreeBSD Here https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L237, it should accept both clang and gcc, This block https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L230 should be removed The issue is not only on FreeBSD but on any system which compiler is clang. side note, the detection of gcc looks at first glance wrong, as on many system gcc is installed as cc sometime. -- components: Distutils messages: 310275 nosy: bapt, dstufft, eric.araujo priority: normal severity: normal status: open title: Bad detection of clang versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32597] Bad detection of clang
Change by bapt : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue32597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25809] "Invalid" tests on locales
New submission from bapt: the locale tests the return value of locale functions against known good values. The problem is when those known good values becomes wrong because of an update of the locales. For example in recent CLDR definition the french separator for thousands in a "non breaking space" and not a space, while it used to be a space. On released FreeBSD (very old db) it was a space. On GNU libc (a more recent db but still old :)) it is a space.On FreeBSD 11 and Dragonfly 4.4 it is a fairly new db (v27.0.1) with the fixed separator: 0xa0! Thant makes this test fail. I have no idea on the way you would prefer to fix that, either remove the test (not sure it is really relevant in the python testsuite) or patch it. https://hg.python.org/cpython/file/tip/Lib/test/test__locale.py#l70 the failures can be seen here: http://buildbot.python.org/all/buildslaves/koobs-freebsd11 -- components: Tests messages: 255964 nosy: bapt, haypo priority: normal severity: normal status: open title: "Invalid" tests on locales type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23817] Consider FreeBSD like any other OS in SOVERSION
New submission from bapt: In the configuration script: https://hg.python.org/cpython/file/47b2d1ff9743/configure.ac#l963 There is a special treatment done for FreeBSD, which is not needed, FreeBSD is perfectly fine with multiple digit in soversion. -- components: Build messages: 239695 nosy: bapt priority: normal severity: normal status: open title: Consider FreeBSD like any other OS in SOVERSION ___ Python tracker <http://bugs.python.org/issue23817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23817] Consider FreeBSD like any other OS in SOVERSION
bapt added the comment: Adding a patch on configure.ac (I bet configure should not be patched but regenerated) Considering the comment here: http://bugs.python.org/issue1044395#msg47064 about ldconfig(1) the output of ldconfig(1) is buggy in that regard, and the ports tree does not depends on that anymore so it will perfectly accept the 2 digit name. There are no known other things depending on that buggy output -- keywords: +patch Added file: http://bugs.python.org/file38759/configure_ac.patch ___ Python tracker <http://bugs.python.org/issue23817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23817] Consider FreeBSD like any other OS in SOVERSION
bapt added the comment: Provide more information: Here is a description of the problem with the FreeBSD ldconfig(1) problem and why it was a problem with libpython.so.* https://wiki.freebsd.org/ports/fix_lib_depends Here is the commit that adds the new methode for ports to lookup for libraries installed (not using ldconfig(1): https://svnweb.freebsd.org/ports?view=revision&revision=322328 here is the commit that removes the ancient method: https://svnweb.freebsd.org/ports?view=revision&revision=362031 -- ___ Python tracker <http://bugs.python.org/issue23817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23817] Consider FreeBSD like any other OS in SOVERSION
bapt added the comment: I do not think it is worth changing python 2.7 or python 3.4 given the fact that the .so.1 symlink is not created (which imho it should be a good idea to create but let's go step by step) Let's just do it for next python -- ___ Python tracker <http://bugs.python.org/issue23817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
