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: unassignedclangb...@nondot.org
Reporter: r...@gcc.gnu.org
CC: kli...@google.com, llvm-bugs@lists.llvm.org,
richard-l...@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
