[llvm-bugs] [Bug 42462] New: Running python tests is fragile
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Jul 1 05:50:37 PDT 2019
https://bugs.llvm.org/show_bug.cgi?id=42462
Bug ID: 42462
Summary: Running python tests is fragile
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: libclang
Assignee: unassignedclangbugs at nondot.org
Reporter: ro at gcc.gnu.org
CC: klimek at google.com, llvm-bugs at lists.llvm.org,
richard-llvm at metafoo.co.uk
I've found several times that running clang's python binding tests is quite
fragile, as witnessed by the number of cases disabling them in
bindings/python/tests/CMakeLists.txt.
There are two issues here:
* It isn't obvious to me why failure to run those tests should break make
check-all. Why is this test so different from a random other test that
just FAILs in such a case?
* What has been bothering me lately is running the binding tests on multilib
targets like Solaris or Linux/x86_64. Only when the python binary in PATH
and lib/libclang.so match (same ELF class, same ABI) will the tests run. On
Solaris 11 there happen to be both 32 and 64-bit python binaries
(/usr/bin/python,
32-bit, and /usr/bin/64/python, 64-bit), so by selecting the proper PATH the
tests *can* run. On Linux/x86_64 however, when building llvm for the
i686-pc-linux-gnu target, libclang.so will be 32-bit while /usr/bin/python
is 64-bit and no 32-bit python is available.
Either the build framework should test that libclang is usable with the python
around (using something like
import ctypes
ctypes.cdll.LoadLibrary("lib/libclang.so")
) or be way less sensitive to mismatches here.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190701/6ce0f335/attachment-0001.html>
More information about the llvm-bugs
mailing list