Jeff Epler <[EMAIL PROTECTED]> writes:
> If we change the linker back to gcc, not g++, will it work if extension
> module 1 gets linked with libstdc++ A and ABI Q, and extension module 2
> gets linked with libstdc++ B and ABI Z?
Yes, unless they are using sys.setdlopenflags to force symbols to be
shared across these extension modules. That's a very intentional act
and should (obviously?) only be undertaken when the extension modules
share an ABI.
> What if a built-in module is written in C++, as it might be for some
> people embedding C++?
"Embedding" usually refers to embedding a _Python_ interpreter in a
program written in some language other than Python. But I think
that's what you meant (just correct me if I'm wrong).
> (this will force use of g++ as the linker, right?)
Yes.
> Don't these cases matter too?
Yes. But the 2nd case is not one in which the Python executable is
being built. The person building a program that embeds Python can
control how (s)he does linking.
> Assuming they can fail now, how will changing the use of CXX as the
> linker fix them?
I don't understand the question.
> Jeff
> PS The Python 2.3 and Python 2.4 binaries installed on my Fedora Core
> machine don't list libstdc++ in `rpm -q --requires python' or `ldd
> /usr/bin/python'. I don't see a patch that would change Python's
> behavior in the SRPM, though. I wonder what the difference is between
> my FC2 and the other systems...
I don't know; the ones we happen to be testing are Debian ("sarge," I
think).
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
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
