Tim Peters [EMAIL PROTECTED] writes:
[Michael Hudson]
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and require the functionality? Inquiring
minds want to know.
I know what it intends to do:
Surprise!
fpectlmodule.c intends to enable the HW
Nobody uses it. It should be ripped out. If someone disagrees, let
them speak up.
On 7/12/05, Michael Hudson [EMAIL PROTECTED] wrote:
Tim Peters [EMAIL PROTECTED] writes:
[Michael Hudson]
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and
David Abrahams wrote:
- ccpython.cc and linking with g++ is removed entirely. or,
That would be bad for C++ users on HP/UX. Is that acceptable?
I hadn't read that far in the threads when I wrote this - I
guess the answer is no, and we must continue to support ccpython.cc.
- the logic is
Martin v. Löwis [EMAIL PROTECTED] writes:
However, you will find that with a), people will still pass --with-cxx,
because they tend to enable all features they can find.
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and require the functionality?
Martin v. Löwis [EMAIL PROTECTED] writes:
- the logic is fixed so that linking with g++ is only done if
main is in ccpython.o
I don't see how that works. Somehow we need to decide whether to put
main in ccpython.o in the first place, don't we?
Yes, that is done through --with-cxx
[Michael Hudson]
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and require the functionality? Inquiring
minds want to know.
I know what it intends to do: fpectlmodule.c intends to enable the HW
FPU divide-by-0, overflow, and invalid operation
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
I don't see how that works. Somehow we need to decide whether to put
main in ccpython.o in the first place, don't we?
You wouldn't have to ask these questions if you had investigated the
answers yourself.
The questions should
David Abrahams wrote:
Yes, and that becomes important in programs that have constructors.
I.e., C++ programs. The Python executable is not such a program,
except for one C++ file: ccpython.cc.
That is not true. ccpython was introduced to support builds of
the Python interpreter where some
Martin v. Löwis [EMAIL PROTECTED] writes:
I don't believe any systems require it. I realize you have said
otherwise, but after years of working with Boost.Python I'm very
familiar with the issues of dynamic linking and C/C++ interoperability
on a wide variety of platforms, and I'm not
On 7/10/05, David Abrahams [EMAIL PROTECTED] wrote:
Martin v. Löwis [EMAIL PROTECTED] writes:
I well remember that gcc 2.5.8 on Linux a.out required this sort of
setup.
Sorry, a.out? Isn't that the default name a C compiler gives to the
executable it builds on Unix? Is it also (part of)
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
Not entirely. By extending Modules/Setup
You mean
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/Setup.dist?view=markup
?
I mean Modules/Setup. It is generated from Modules/Setup.dist
(plus some
David Abrahams wrote:
I well remember that gcc 2.5.8 on Linux a.out required this sort of
setup.
Sorry, a.out? Isn't that the default name a C compiler gives to the
executable it builds on Unix? Is it also (part of) the name of an OS?
Yes, and somewhat. It is also the name of a binary
David Abrahams wrote:
- we add a configure test that runs after the existing test
determines that --with-cxx is needed (but not when --with-cxx is
explicitly specified on the command line)
- This test runs a 'C' executable that tries to load a C++ dynamic
library with
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
- we add a configure test that runs after the existing test
determines that --with-cxx is needed (but not when --with-cxx is
explicitly specified on the command line)
- This test runs a 'C' executable that tries to
David Abrahams schrieb:
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
Unless, of course, I'm missing something. So if I am missing
something, what is it?
You are missing something, and I can only repeat myself. Some systems
require main() to be compiled as
Ulrich Berning [EMAIL PROTECTED] writes:
If you build C++ extensions on HP-UX with aCC, Python must be compiled
and linked as a C++ program. This is documented.
You mean dynamically loaded C++ extensions, or the kind that are
linked into the Python executable?
I'm willing to believe almost
David Abrahams schrieb:
Ulrich Berning [EMAIL PROTECTED] writes:
If you build C++ extensions on HP-UX with aCC, Python must be compiled
and linked as a C++ program. This is documented.
You mean dynamically loaded C++ extensions, or the kind that are
linked into the Python executable?
Ulrich Berning [EMAIL PROTECTED] writes:
David Abrahams schrieb:
Ulrich Berning [EMAIL PROTECTED] writes:
If you build C++ extensions on HP-UX with aCC, Python must be
compiled and linked as a C++ program. This is documented.
You mean dynamically loaded C++ extensions, or the kind
David Abrahams wrote:
Unless, of course, I'm missing something. So if I am missing
something, what is it?
You are missing something, and I can only repeat myself. Some systems
require main() to be compiled as C++, or else constructors may not work
(and perhaps other things fail as well). The
David Abrahams wrote:
If there is some library with such objects that happens to get
wrapped and dynamically linked into a Python interpreter
Whoa there. How would that ever happen under ordinary circumstances?
Doesn't Python's makefile control what gets linked to Python?
Not entirely. By
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
If there is some library with such objects that happens to get
wrapped and dynamically linked into a Python interpreter
Whoa there. How would that ever happen under ordinary circumstances?
Doesn't Python's makefile control
Apparently Python on some linux distros is being linked by g++ rather
than gcc, resulting in the C++ runtime library being linked into
Python; this has bad consequences for compatibility between C++
extension modules and Pythons that have been built with different
versions of GCC. Is this
David Abrahams wrote:
Apparently Python on some linux distros is being linked by g++ rather
than gcc, resulting in the C++ runtime library being linked into
Python; this has bad consequences for compatibility between C++
extension modules and Pythons that have been built with different
Sjoerd Mullender [EMAIL PROTECTED] writes:
David Abrahams wrote:
Apparently Python on some linux distros is being linked by g++ rather
than gcc, resulting in the C++ runtime library being linked into
Python; this has bad consequences for compatibility between C++
extension modules and
Configure with --without-cxx to not use g++. Since there is an
option in configure, I assume it is intentional.
Dave O-kay... any idea what the rationale for this decision might be?
I believe it's so that people can link in libraries written in C++ and have
them initialized
Skip Montanaro [EMAIL PROTECTED] writes:
Configure with --without-cxx to not use g++. Since there is an
option in configure, I assume it is intentional.
Dave O-kay... any idea what the rationale for this decision might be?
I believe it's so that people can link in libraries
Skip Montanaro [EMAIL PROTECTED] writes:
I believe it's so that people can link in libraries written in C++
and have them initialized properly.
Dave Can you give specifics? What do you mean by link in? Do you
Dave mean statically link into the Python interpreter, or
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
Apparently Python on some linux distros is being linked by g++ rather
than gcc, resulting in the C++ runtime library being linked into
Python; this has bad consequences for compatibility between C++
extension modules and Pythons
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
Jeff Epler wrote:
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?
The problem is that it won't link at all. Compiling Modules/ccpython.o
using g++ creates (in
30 matches
Mail list logo
