> I'm not an expert here, but this is why we've tried to avoid exposing > C++ functions into the public API. As long as the public API stays C, > we only require that LLVM and Python are compiled with the same > compiler, right?
Possibly not. You may end up loading two different C++ runtimes into address space (e.g. the g++ one and the SunPRO one). If your OS has a global single-level symbol space (such as traditional SysV, or Linux), and if then the C++ libraries also have common function names but give different meanings to the same function, you lose. In practice (and in the past), this didn't really cause that much problems in itself, as the C++RTs where likely to use different name mangling, so they wouldn't have overlapping function names. What the situation is today can best be determined by testing. > I could imagine a problem if Python+LLVM link in one libstdc++, and an > extension module links in a different one, even if no C++ objects are > passed across the boundary. Does that cause problems in practice? We'd > have the same problems as from having two different C runtimes in the > same application. This typically doesn't happen, on Unix, as the CRT is provided by the system vendor, and even third-party C compilers still link to the system library (which is possible because the system vendor also includes header files with the system). For C++, having a standard ABI is not yet that common (although Linux has established one which at least the Intel compiler complies with). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
