================ @@ -0,0 +1,22 @@ +def is_libclang_loadable(): + try: + sys.path.append(os.path.join(config.clang_src_dir, "bindings/python")) + from clang.cindex import Config + conf = Config() + Config.set_library_path(config.clang_lib_dir) + conf.lib + return True + except Exception as e: + # Benign error modes. + if "wrong ELF class: ELFCLASS32" in str(e): + return False + elif "No such file or directory" in str(e): + return False + # Unknown error modes. + else: + return True ---------------- rorth wrote:
The intent (and it worked for me) is as follows: - If `libclang.so` cannot be loaded, this can be for two reasons so far: - In a 32-bit build on a 64-bit system, the resulting 32-bit `libclang.so` cannot be loaded into the system's 64-bit `python`. This is as expected, nothing to be done about that, thus the lib is truely considered unloadable. - If `libclang.so` is missing completely, this must be because building it has been disabled somehow (probably with `-DLLVM_ENABLE_PIC=OFF`. Again, this is intentional and nothing to be done. - However, in other cases there may well be a bug lurking here. Consider (just for the sake of argument) a `libclang.so` matching `python`'s ELF class, but built with missing dependencies so it's not self-contained and cannot be loaded. This is simply a bug that could/should be fixed. Therefore, I return `True` for unknown/unhandled errors, which lets the test to `FAIL`, forcing investigation. The failure may be benign yet not currently handled, or there may be a real bug that needs fixing. If I always return `False` on a failure to load `libclang.so`, such bugs would go unnoticed. https://github.com/llvm/llvm-project/pull/142948 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
