Re: [Python-Dev] [C++-sig] GCC version compatibility
On Sun, Aug 07, 2005 at 11:11:56PM +0200, Martin v. Löwis wrote: I've looked at the patch, and it looks fairly safe, so I committed it. Thanks. I did not forget my promise to look into a more comprehensive approach to the C++ build issues. But I first need to better understand the potential impact on distutils. And, foremost, I need to finish my thesis whence my spare time projects go very slowly. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html ___ 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
Re: [Python-Dev] [C++-sig] GCC version compatibility
On Sun, Jul 17, 2005 at 04:01:20PM +1000, Anthony Baxter wrote: On Saturday 16 July 2005 20:13, Christoph Ludwig wrote: I submitted patch #1239112 that implements the test involving two TUs for Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but that will take some time. I'm only vaguely aware of all of the issues here with linking, but if this is to be considered for 2.4.2, it needs to be low risk of breaking anything. 2.4.2 is a bugfix release, and I'd hate to have this break other systems that work... I prepared the patch for 2.4.2 since it is indeed a bugfix. The current test produces wrong results if the compiler is GCC 4.0 which inhibits a successful build of Python 2.4. I tested the patch with GCC 2.95, 3.3 and 4.0 - those are the only compilers I have easy access to right now. I do not see how this patch could cause regressions on other platforms because it mimics the situation w.r.t. ccpython.cc: A C++ translation unit calls from main() an extern C function in a separate C translation unit. The test determines whether it is possible to produce an intact executable if the C compiler is used as linker driver. If this test causes problems on some platform then you'd expect trouble when linking the python executable out of ccpython.o and all the other C object modules anyway. But, of course, I might be wrong. I do not claim that I am familiar with every platform's peculiarities. That's why the patch is up for review. I'd appreciate if users on other platforms test it. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html ___ 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
Re: [Python-Dev] [C++-sig] GCC version compatibility
On Tue, Jul 12, 2005 at 01:07:56AM +0200, Martin v. Löwis wrote: Christoph Ludwig wrote: Yes, but on ELF/Linux the default configuration should be --without-cxx in the first place. If the build instructions make it sufficiently clear that you should prefer this configuration whenever possible then this should be a non-issue on platforms like ELF/Linux. Some users will complain about this. Specifying --without-cxx also causes configure not to look for a C++ compiler, meaning that distutils won't know what the C++ compiler is, meaning that it will link extension modules with the C compiler instead. If I understood Dave Abraham's reply somewhere above in this thread correctly then you can build different C++ extension modules with different C++ compilers on ELF/Linux. (I don't have the time right now to actually try it, sorry.) There is no need to fix the C++ compiler as soon as python is built. If distutils builds C++ extensions with the C compiler then I consider this a bug in distutils because it is unlikely to work. (Unless the compiler can figure out from the source file suffixes in the compilation step *and* some info in the object files in the linking step that it is supposed to act like a C++ compiler. None of the compilers I am familiar with does the latter.) distutils should rather look for a C++ compiler in the PATH or explicitly ask the user to specify the command that calls the C++ compiler. It is different if --with-cxx=compiler was used. I agree that in this case distutils should use compiler to build C++ extensions. (distutils does not behave correctly when building C++ extensions anyway. It calls the C compiler to compile the C++ source files and passes options that gcc accepts only in C mode. The compiler version I am using is docile and only issues warnings. But these warnings are unnecessary and and I would not blame gcc if the next compiler release refused to compile C++ sources if the command line contains C specific options. But the distutils mailing list is a better place to bring this eventually up, I guess.) Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html ___ 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
Re: [Python-Dev] [C++-sig] GCC version compatibility
On Sun, Jul 10, 2005 at 09:45:25AM +0200, Martin v. Löwis wrote:
Christoph Ludwig wrote:
I'll describe it once more: *If* a program is compiled with the C++
compiler, is it *then* possible to still link it with the C compiler?
This is the question this test tries to answer.
The keyword here is tries
Any such test would only try: to really determine whether this is
necessary for all possible programs, one would have to test all possible
programs. Since there is an infinite number of programs, this test could
take a while.
Sure. You cannot write a test that gives the correct result for all platforms
you can think of, covering every compiler / linker quirk. I never claimed that
is possible.
My point is: The test implemented in the 2.4.1 configure script gives a wrong
result if your platform happens to be x86 Linux with ELF binaries and
g++ 4.0.
The original test, on the original system, would cause __main to be
undefined, and then decide to use C++. For a long time, on systems
that don't use collect2, the test *correctly* determined that linking
with g++ was not necessary.
It is only recent changes to g++ that break the test, namely the
introduction of this __gxx_personality_v0 thing.
The test broke due to a change in GCC 4.0, but the __gxx_personality_v0
thing was introduced long before. It is merely a symptom. I ran the tests
with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results:
GCC version 1 TU2 TUs
3.3.1g++ g++
3.4.2g++ g++
4.0.0gcc g++
(1 TU: test with one translation unit, as in Python 2.4.1.
2 TUs: test with two translation units, as in my last posting.
g++ / gcc: test indicates linking the executable requires g++ / gcc,
respectively.)
With GCC 3.3.1 and 3.4.2, linking of the executable conftest in the 1 TU test
fails because of an unresolved symbol __gxx_personality_v0. Therefore, python
is linked with g++.
The change that makes GCC 4.0.0 break the 1 TU test is that the compiler
apparently does a better job eliminating unreachable code. In the 1 TU test,
it recognizes __gxx_personality_v0 (or the code that refers to this symbol) is
unreachable and removes it. It seems there are no other symbols left that
depend on libstdc++ so suddenly conftest can be linked with gcc.
- my bug report #1189330 exihibts that the test
fails to do its job. And looking at the test that's certainly no surprise:
However, it *is* a surprise that your modified test fixes the problem.
Note that there is *no* reference to any symbol in another TU. The compiler
can detect that foo() won't throw any exceptions, that there is no need for
RTTI
and whatever else the C++ runtime provides. Consequently, the object file
produced by g++ does not contain any reference to symbols in libstdc++.
You are assuming implementation details here. I have seen
implementations of C++ (eg. g++ with collect2) where the test determines
that linking with C++ is necessary (because __main was undefined), as
well as systems where the test decides *correctly* that linking with
C++ is not necessary (e.g. gcc 2.x on an ELF system). That some C++
compiler introduces the C++ runtime if some C function may throw an
exception is a very specific detail of this C++ compiler.
I am not aware of any rule that makes the following program ill-formed:
// in a.cc:
extern C void foo();
int main() {
foo();
}
// in b.cc
extern C void foo() {
throw 1;
}
Provided the compiler does not do optimizations across translation units, it
has no way to determine in a.cc whether foo() is really a C function (i.e.,
compiled by a C compiler) or a C++ function with C linkage. I think a
conforming C++ compiler has to provide for the case that foo() might throw. It
was a very specific detail of gcc 2.x if it failed to do so. (A venial
omission, I admit.)
But I digress. It's not that important for our discussion whether a C++
compiler must / should / is allowed to add exception handling code to the
call of an extern C function. The point is that some do *unless* they see
the function definition. I contend the test involving two TUs matches more
closely the situation with ccpython.cc than the current test.
I do not claim the 2 TUs test will cover all possible scenarios. I am not even
sure this decision should be left to an automated test. Because if the test
breaks for some reason then the user is left with a linker error that is
time-consuming to track down.
Of course, if you insist on this dependency optimization then you can try
to
fix Python's configure.in by using the second test above. But I would still
not trust it to cover all configurations on all platforms supported by
Python.
Of couse not. This is just autoconf: it does not allow magical porting
to all possible future operating systems. Instead, from time to time,
explicit porting activity is necessary. This is not just about
Re: [Python-Dev] [C++-sig] GCC version compatibility
On Sun, Jul 10, 2005 at 09:35:33AM -0400, David Abrahams wrote: Christoph Ludwig [EMAIL PROTECTED] writes: I do not claim the 2 TUs test will cover all possible scenarios. I am not even sure this decision should be left to an automated test. Because if the test breaks for some reason then the user is left with a linker error that is time-consuming to track down. However, at least by the usual hierarchy of values, the sort of runtime error that results from the current needless linking with C++ on ELF/Linux is even worse. Yes, but on ELF/Linux the default configuration should be --without-cxx in the first place. If the build instructions make it sufficiently clear that you should prefer this configuration whenever possible then this should be a non-issue on platforms like ELF/Linux. We learned that there are indeed platforms that require --with-cxx. There is not much we can do for user on platforms that that also require the final executable to be linked with the C++ compiler. They have to live with the dependency on the C++ runtime and the likely runtime errors if the import extension modules built with a different C++ compiler. What about the platforms that require compilation of main() with a C++ compiler but allow you to link with the C compiler - can you import a C++ extension module built with C++ compiler version X if the main() function of the Python interpreter was compiled with C++ compiler version Y, X != Y? If not, then we are back to the runtime error, no matter whether there is a dependency on the C++ runtime library or not. So the automated test in configure could spare users runtime errors if they must configure --with-cxx and if they can link with the C compiler and if the C++ compiler versions used for building the Python interpreter and the extension module do not need to coincide. I don't know how large the subset of platforms is that satisfy these conditions. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html ___ 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
Re: [Python-Dev] [C++-sig] GCC version compatibility
On Sat, Jul 09, 2005 at 12:08:08AM +0200, Martin v. Löwis wrote:
David Abrahams wrote:
When I looked into this problem I saw that configure in fact builds a test
executable that included an object file compiled with g++. If the link step
with gcc succeeds then LINKCC is set as above, otherwise CXX is
used. Obviously, on my system this test was successful so configure decided
to link with gcc. However, minimal changes to the source of the test program
caused the link step to fail. It was not obvious to me at all why the latter
source code should cause a dependency on the C++ runtime if the original
code does not. My conclusion was that this test is fragile and should be
skipped.
Sounds like it. I have never understood what the test was really
checking for since the moment it was first described to me, FWIW.
I'll describe it once more: *If* a program is compiled with the C++
compiler, is it *then* possible to still link it with the C compiler?
This is the question this test tries to answer.
The keyword here is tries - my bug report #1189330 exihibts that the test
fails to do its job. And looking at the test that's certainly no surprise:
configure writes the following conftest.cc on the disk (whitespaces added for
better readability):
[EMAIL PROTECTED]:~/tmp/python-config cat conftest.cc
void foo();
int main() {
foo();
}
void foo() {
}
This TU is compiled with the C++ compiler and then linked with the C compiler:
[EMAIL PROTECTED]:~/tmp/python-config g++ -o conftest.o -c conftest.cc
[EMAIL PROTECTED]:~/tmp/python-config gcc -o conftest conftest.o
Note that there is *no* reference to any symbol in another TU. The compiler
can detect that foo() won't throw any exceptions, that there is no need for RTTI
and whatever else the C++ runtime provides. Consequently, the object file
produced by g++ does not contain any reference to symbols in libstdc++.
However, python.c does reference a function from other TUs, in particular
extern C int Py_Main(int, char**). The following test shows that in this
situation you must link with g++:
[EMAIL PROTECTED]:~/tmp/python-config cat conftest_a.cc
extern C void foo();
int main() {
foo();
}
[EMAIL PROTECTED]:~/tmp/python-config cat conftest_b.c
void foo() {
}
[EMAIL PROTECTED]:~/tmp/python-config g++ -o conftest_a.o -c conftest_a.cc
[EMAIL PROTECTED]:~/tmp/python-config gcc -o conftest_b.o -c conftest_b.c
[EMAIL PROTECTED]:~/tmp/python-config gcc -o conftest conftest_a.o
conftest_b.o
conftest_a.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld gab 1 als Ende-Status zurück
(I ran this test with g++ 3.3.1, 3.4.2, and 4.0.0 with identical results.) The
reason is, I guess, that even though foo() is delared to have C linkage, it
still can throw a C++ exception.
If Python is built with --with-cxx then it should be linked with CXX
as well.
U betcha.
Wrong. The test was introduced in response to complaints that Python
unnecessarily links with libstdc++ on some Linux systems. On these
Linux systems, it was well possible to build main() with a C++ compiler,
and still link the entire thing with gcc. Since main() doesn't use
any libstdc++ functionality, and since collect2/__main isn't used,
one would indeed expect that linking with CXX is not necessary.
Of course, if you insist on this dependency optimization then you can try to
fix Python's configure.in by using the second test above. But I would still
not trust it to cover all configurations on all platforms supported by
Python.
(On ELF based Linux/x86, at least.) That leaves me wondering
* when is --with-cxx really necessary?
I think it's plausible that if you set sys.dlopenflags
This has no relationship at all. --with-cxx is much older than
sys.dlopenflags. It is used on systems where main() must be a
C++ program for C++ extension modules to work (e.g. some Linux
systems).
Can you provide a concrete examples of such systems? The explanation of
--with-cxx in the README mentions a.out. Are there other systems?
Regards
Christoph
--
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
___
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
