Re: [Python-Dev] Linux Python linking with G++?
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 modules are C++. As you know, people do write extension modules in C++. > There is no reason that file > couldn't be rewritten as a pure 'C' file and any need for Python to be > linked with G++ would disappear. There is already a version of that file in C, Modules/python.c. This is used when --with-cxx is not given. >>The configure option --with-cxx (documented as "enable C++ support") >>make Python C++ options work on such systems. > > > What are "Python C++ options?" Oops, meant "Python C++ extension modules" (it must have been late when I wrote that). >>I could personally accept if ccpython and --with-cxx would be dropped >>entirely (i.e. deliberately breaking systems which require it); > > > 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 convinced by your > assertion. If such a system exists, it should be easy for someone to > point me at it, and show that something breaks. I well remember that gcc 2.5.8 on Linux a.out required this sort of setup. Dynamic linking was not supported at all on that system (atleast not in a way where users could easily write shared libraries themselves). Rebuilding the Python interpreter was the only option to integrate additional modules. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GCC version compatibility
David Abrahams 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. > > > Okay, I understand that. What I have never understood is why that > should be an appropriate thing to test for the Python executable. > There's no reason to compile any of Python with a C++ compiler. I hope you understand now: it is necessary if you want to link C++ extension modules into a Python interpreter (statically, not dynamically). >>Wrong. The test was introduced in response to complaints that Python >>unnecessarily links with libstdc++ on some Linux systems. > > > Apparently it still does. Not "still", but "again", since recent changes in gcc. >>On these Linux systems, it was well possible to build main() with a >>C++ compiler > > > Nobody would need to build Python's main() with a C++ compiler, if > you'd just comment out the 'extern "C"'. Wrong. People that statically link C++ extensions modules on systems where the C++ compiler requires main to be compiled as C++ need to do such a thing. One such compiler is gcc on systems where the binary format does not support .init sections. >>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. > > > It isn't. Hmmm. It is. Try for yourself. You get an unresolved gxx_personality_v0. > I have tested Boost.Python and C++ extension modules on a wide variety > of Linux systems, and have seen this phenomenon. Did you try on Linux systems released 1994? That don't use ELF as the binary format? > I think either the ELF Linux loader changed substantially since 1995, > or whoever introduced this test was just confused. No. The ELF loader was *introduced* since 1995. Dynamic loading was not available before. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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 additional information) in the build process. > I contend that either: > >a. Anyone making that sort of extension with a C++ module should >explicitly request --with-cxx, or > >b. The python build system should automatically detect that >--with-cxx is needed based on the presence of C++ extension >modules. > > Frankly I think b. would require an impractical amount of work and, > speaking as an author of C++ extension modules, I don't think a. is > much of a burden to impose. It is the burden of change. Contributions are welcome. However, you will find that with a), people will still pass --with-cxx, because they tend to "enable" all features they can find. I personally could accept --with-cxx and ccpython.cc to be removed again, but I'm uncertain whether that may break distutils in some way. Regards, Martin ___ Python-Dev mailing list [email protected] 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
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. 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. > - 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. > 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 this specific detail, but about many other details. Each new operation system, library, or compiler version might break the build process. > Can you provide a concrete examples of such systems? The explanation of > --with-cxx in the README mentions a.out. Are there other systems? I'm not sure. I think HP-UX (with OMF, and aCC) might have required the same code, as may have SysVR3 (with COFF). Regards, Martin ___ Python-Dev mailing list [email protected] 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 bindings calling tmpfile() blocks interrupt signal
On 07/07/05, Michael Hudson <[EMAIL PROTECTED]> wrote: >> > > But with my threaded Python code, SIGINT doesn't work anymore after my > > binding has called tmpfile(). > > Oh, threads. > > Which version of Python are you using? 2.3.5, the one that ships with Mac OS X 10.4. I have a 2.4.x install somewhere, I'll give it a go. But you're right, it's probably because of threads. Now I'm trying to determine whether this is a Python bug or a Mac OS X bug... Florent -- Florent Pillet http://www.florentpillet.com Freelance software developer/consultant - Palm OS & Mac OS X ICQ: 117292463Skype: callto://florent.pillet ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/6/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > However, while I prefer what you describe to Python's current > behaviour, I am not yet convinced the backward compatibility pain is > worth it. Adding yet-another-kind-of-string-literal (when we already > have bytestrings on the horizon) is also unappealing. First off, thanks for your feedback--you raise some very good points that I have addressed insufficiently or not at all. I personally feel that backward compatibility issues provide the strongest argument against accepting the proposal (but obviously I find the rest of it favourable :-). It may not be particularly clear (that's why it's a draft) that I am not proposing another kind of string literal, but rather a change of rules for an existing one. > Your readability examples are good, but the first two involve strings > that should probably be module level constants (as Terry described) > and the test case involving expected output is probably better handled > using doctest, which has its own mechanism for handling indentation. I think the question of whether an inline string should be made a module-level constant (or moved to a separate file entirely) relates in general to higher-level considerations of readability and program structure (similar, for example, to those that would prompt one to refactor a function). IOW, the answer to that question would be the same with or without this proposal. In any case, I chose the examples (from different parts of the standard library) more because they illustrated different classes of usage for TQS's than because they were the best illustrations of readability improvement--perhaps something I should address. > Raw and unicode string literals need to be mentioned in the PEP. Which > literals would the reformatting apply to? All 3? Only standard and > unicode, leaving raw strings alone? The proposal would apply to all 4 :-) -- normal, raw, unicode, and raw unicode. > You should research the reasons why PEP 295 [1] was rejected, and > describe in the new PEP how it differs from PEP 295 (unfortunately PEP > 295 was not updated with the rationale for rejection, but this post > [2] looks like Guido putting the final nail in its coffin). THANK YOU! In my research for this, I didn't come across PEP 295 at all -- perhaps due to the fact that it uses the term "multiline strings" exclusively, which is not how I would describe them at all. I will certainly address this in my next draft. Cheers, Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI. In what way? The scheme described is explicit, and consistently applied to all triple-quoted strings[*] -- although the rules are different to the current behaviour. On the other hand, my written proposal may not be clear or explicit, something I will attempt to remedy over the next few days. [*] Whether it should apply also to normal strings with escaped newlines is not something I have yet considered. Andrew ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/7/05, Terry Reedy <[EMAIL PROTECTED]> wrote: > > I believe there were some current alternatives and concerns already > expressed that have not been included yet that maybe should be. Yes; Nick pointed me to one, and I'll be looking at that and the related discussions before redrafting; I'll also have a further look for other similar proposals. > Some of your examples look worse than needed by putting the first line > after the triple quote instead of escaping the first newline like you did > elsewhere. In general, I wanted to preserve as much as possible the way that the string was originally written (as these examples were taken and adapted from the standard library source). In the example with the embedded python code, I felt it was significantly clearer if the initial newline was escaped. > Having separate rules for doc strings and other tq strings would be a > nuisance. I totally agree -- and if the proposal as written gives that impression then I'll correct it. What I was trying to say about docstrings was that the change would have no effect on the result after processing them with docutils or anything else that follows PEP 257 -- which is very significant in terms of backward compatibility, as docstrings are AFAICT the leading use of TQS's (by a large margin). Cheers, Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
Guido van Rossum wrote: > On 7/5/05, Andrew Durdin <[EMAIL PROTECTED]> wrote: >> I have written a patch that changes the way triple-quoted strings are >> scanned so that leading whitespace is ignored in much the same way >> that pep 257 handles it for docstrings. Largely this was for a >> learning experience in hacking the parser, but it would be very nice >> IMO if something of this sort could be implemented in a future version >> of Python. > > I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI. Another idea, which is much more conservative: textwrap.dedent is highly under- rated and hidden. Why not make it builtin or a string method? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
"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 convinced by your >> assertion. If such a system exists, it should be easy for someone to >> point me at it, and show that something breaks. > > 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? > Dynamic linking was not supported at all on that system (atleast > not in a way where users could easily write shared libraries > themselves). Rebuilding the Python interpreter was the only option > to integrate additional modules. Understood, and I retract my former incredulity. I believe HP-UX requires it, and I believe that some systems where you have to link in extension modules explicitly require it. But the "--with-cxx if configure says you can get away with it" behavior is hurting on a major platform: ELF Linux. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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) the name of an OS? It's the name of an executable format that predates ELF. I don't know if it's in current use anywhere. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
"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 additional information) in the build process. > >> I contend that either: >> >>a. Anyone making that sort of extension with a C++ module should >>explicitly request --with-cxx, or >> >>b. The python build system should automatically detect that >>--with-cxx is needed based on the presence of C++ extension >>modules. >> >> Frankly I think b. would require an impractical amount of work and, >> speaking as an author of C++ extension modules, I don't think a. is >> much of a burden to impose. > > It is the burden of change. Well, as you say: What *has* changed now is that the configure test suddenly determines that you need to link with g++ on Linux if main was compiled with g++. This was not the case before, but now is (since g++ 3.2 or something). > Contributions are welcome. Let me first try to discover what contribution would be acceptable. What if: - 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 dlopen. - The test returns an error code if the the dynamic library's static and dynamic initializers have not been run properly - If the test fails we disable --with-cxx ?? I'm trying to intrude on the existing behavior as little as possible, yet get the semantics we want for ELF/Linux in a way that stands a good chance of generalizing to other platforms. > However, you will find that with a), people will still pass --with-cxx, > because they tend to "enable" all features they can find. That's acceptable to me. We could probably circumvent some of those cases by improving the configure --help text. > I personally could accept --with-cxx and ccpython.cc to be removed > again, but I'm uncertain whether that may break distutils in some > way. Well, that would certainly be an easy "solution," but it would break HP/UX, and it would break anyone that needs to statically link C++ modules on some platforms. It's a much more drastic change than it would be to only have the system use --with-cxx when the person running configure asks for it explicitly. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GCC version compatibility
Christoph Ludwig <[EMAIL PROTECTED]> writes: > --with-cxx=: If you plan to use C++ extension modules, then on some > platform you need to compile python's main() function with the C++ > compiler. With this option, make will use to compile main() > *and* to link the python executable. It is likely that the resulting > executable depends on the C++ runtime library of . > > Note there are platforms that do not require you to build Python with > a C++ compiler in order to use C++ extension modules. E.g., x86 Linux > with ELF shared binaries and GCC 3.x, 4.x is such a platform. We > recommend that you configure Python --without-cxx on those platforms > to avoid unnecessary dependencies. I don't think that's strong enough. What happens is that dynamically loaded Python extension modules built with other, ABI-compatible versions of G++ may *crash*. > If you need to compile main() with , but your platform does > not require that you also link the python executable with > (e.g., ), then set LINKCC='$(PURIFY) $(CC)' prior to > calling make. Then the python executable will not depend on the C++ > runtime library of . Are we sure we have an actual use case for the above? Doesn't --without-cxx cover all the actual cases we know about? > BTW, I'd also change the short explanation output by `configure --help'. > Something like: > > AC_HELP_STRING(--with-cxx=, > use to compile and link main()) > > In Python 2.4.1, the help message says "enable C++ support". That made me use > this option even though it turned out it is not necessary on my platform. Your suggestion is simple and powerful; I like it! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GCC version compatibility
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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list [email protected] 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
--- David Abrahams <[EMAIL PROTECTED]> 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. Indeed. A few months ago the current configure behavior lead to a major loss of our time, probably a whole week between 4-5 people. The problem was that a Python compiled under RH 8.0 was used to build and run new C++ extensions under Fedroa Core 3. Some extensions ran OK, others crashed without warning after running to a certain point. It was very confusing. To avoid this situation in the future, we permanently added a test to our setup scripts, comparing the result of ldd python | grep libstdc++ to the corresponding output for extension modules. Cheers, Ralf Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
Andrew Durdin <[EMAIL PROTECTED]> wrote: > > On 7/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > I don't think so. It smells too much of DWIM, which is very unpythonic. > > EIBTI. > > In what way? The scheme described is explicit, and consistently > applied to all triple-quoted strings[*] -- although the rules are > different to the current behaviour. On the other hand, my written > proposal may not be clear or explicit, something I will attempt to > remedy over the next few days. You are wrong. Current string literals are explicit. They are what you type. What you propose is to force all string literals to be /implicitly/ preprocessed by the compiler, an operation that /necessarily/ loses information. The current mechanism that works behind the scenes for docstrings does /no/ preprocessing of string literals used as docstrings*. Why? Because the designers realized that doing so may break source that relies on those docstrings for precise indentation. Right now, your (implicit preprocessing of triple quoted strings) proposal may change the output of various report generation softwares. Specifically, ones who use a 'header-line' for the names of columns... print ''' column column column''' > [*] Whether it should apply also to normal strings with escaped > newlines is not something I have yet considered. When you have to start differentiating, or consider differentiating, how preprocessing occurs based on the existance or non-existance of escaped newlines, you should realize that this has a serious "Do what I mean" stink (as Guido has already stated, more politely). I propose that we keep all string literals /literal/, not only those lacking triple-quoting. Any processing that needs to be done to /any/ string (literal or otherwise), should be explicitly asked for. Is that too much to ask? - Josiah [*] >>> def foo(): ... ''' ... x ... y ... z ... ''' ... >>> help(foo) Help on function foo in module __main__: foo() x y z >>> print foo.__doc__ x y z >>> ___ Python-Dev mailing list [email protected] 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
Christoph Ludwig wrote: > 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. Point well taken. >>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: As I say: it's a recent change (GCC 3.3 *is* recent). >>You are assuming implementation details here. > > I am not aware of any rule that makes the following program ill-formed: And I didn't suggest that such a rules exists. Your proposed modification to the test program is fine with me. > 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. Maybe. For Python 2.4, feel free to contribute a more complex test. For Python 2.5, I would prefer if the entire code around ccpython.cc was removed. > Instead of having yet another test in configure.in that may break on a new > platform and that needs maintenance wouldn't it be better to assume that > --with-cxx implies linking with the C++ compiler and telling users how to > override this assumption? Would it cause so much inconvenience to users > provided the explanation of --with-cxx in the README would be modified? *If* the configure algorithm is modified, I think I would prefer if the feature was removed entirely. > In Python 2.4.1, the help message says "enable C++ support". That made me use > this option even though it turned out it is not necessary on my platform. For 2.4.2, things should essentially stay the way they are, except perhaps for fixing bugs. For 2.5, more radical changes are possible. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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 format, see /usr/include/a.out.h (*). There are different types of object files: OMAGIC (.o), NMAGIC,ZMAGIC,QMAGIC (executable), CMAGIC (core file). The Linux inplementation is now called binfmt_aout, but it used to be the only binary format that Linux supported up to Linux 1.2 (which introduced ELF in 1.1.52). Originally, a.out did not support shared libraries, but was extended to do so by allocating fixed virtual addresses to well-known shared libraries, so that no relocation was necessary (the a.out dynamic loader did not support either dynamic relocation nor PIC code on Linux; the SunOS dynamic linker did support relocation AFAIR). Even after Linux implemented ELF, it took some time for distributions to switch to ELF. Because of the startup overhead, there was some reluctance that ELF is "slower"; it also created larger executables. Only when developers realized how powerful dynamic linking and shared libraries are, they gave up their concerns. > Understood, and I retract my former incredulity. I believe HP-UX > requires it, and I believe that some systems where you have to link in > extension modules explicitly require it. But the "--with-cxx if > configure says you can get away with it" behavior is hurting on a > major platform: ELF Linux. Indeed. Regards, Martin (*) Actually, the format is called this way *because* it is the format of the compiler output file. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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 dlopen. > > - The test returns an error code if the the dynamic library's static > and dynamic initializers have not been run properly > > - If the test fails we disable --with-cxx > > ?? What would be the purpose of such a test? The test may fail for many reasons, for example, dlopen might not be available. OTOH, on current Linux systems the test would succeed, so configure would conclude to link with g++. > I'm trying to intrude on the existing behavior as little as possible, > yet get the semantics we want for ELF/Linux in a way that stands a > good chance of generalizing to other platforms. I now think that the code should be made more simple, not more complex. Aspects of a solution I could accept: - ccpython.cc and linking with g++ is removed entirely. or, - the logic is fixed so that linking with g++ is only done if main is in ccpython.o - the configure test is extended to better match current g++ behaviour. > Well, that would certainly be an easy "solution," but it would break > HP/UX, and it would break anyone that needs to statically link C++ > modules on some platforms. It's a much more drastic change than it > would be to only have the system use --with-cxx when the person > running configure asks for it explicitly. I just checked, and it seems that the logic in use is still somewhat different. If the configure test determines that a C++ main() must be linked with CXX, it unconditionally changes the linker to CXX. The test, in turn, is run always if a C++ compiler was found, i.e. independently of whether --with-cxx was provided. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/10/05, Andrew Durdin <[EMAIL PROTECTED]> wrote: > On 7/7/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > I don't think so. It smells too much of DWIM, which is very unpythonic. > > EIBTI. > > In what way? The scheme described is explicit, and consistently > applied to all triple-quoted strings[*] -- although the rules are > different to the current behaviour. On the other hand, my written > proposal may not be clear or explicit, something I will attempt to > remedy over the next few days. The scheme may be explicitly spelled out in the language reference, but it is implicit to the human reader -- what you see is no longer what you get. > [*] Whether it should apply also to normal strings with escaped > newlines is not something I have yet considered. I recommend that you give it up. You ain't gonna convince me. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
"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 load a C++ dynamic >> library with dlopen. >> >> - The test returns an error code if the the dynamic library's static >> and dynamic initializers have not been run properly >> >> - If the test fails we disable --with-cxx >> >> ?? > > What would be the purpose of such a test? The test may fail for many > reasons, for example, dlopen might not be available. I was assuming we only disable --with-cxx if the test builds successfully. I presume dlopen will fail linking if it's unavailable? > OTOH, on current Linux systems the test would succeed, so configure > would conclude to link with g++. Uhh, whoops. Change the sense of my last bullet - If the test passes we disable --with-cxx >> I'm trying to intrude on the existing behavior as little as possible, >> yet get the semantics we want for ELF/Linux in a way that stands a >> good chance of generalizing to other platforms. > > I now think that the code should be made more simple, not more complex. > Aspects of a solution I could accept: > > - ccpython.cc and linking with g++ is removed entirely. or, That would be bad for C++ users on HP/UX. Is that acceptable? > - 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? > - the configure test is extended to better match current g++ > behaviour. What do you have in mind? >> Well, that would certainly be an easy "solution," but it would break >> HP/UX, and it would break anyone that needs to statically link C++ >> modules on some platforms. It's a much more drastic change than it >> would be to only have the system use --with-cxx when the person >> running configure asks for it explicitly. > > I just checked, and it seems that the logic in use is still somewhat > different. If the configure test determines that a C++ main() > must be linked with CXX, it unconditionally changes the linker to CXX. > The test, in turn, is run always if a C++ compiler was found, > i.e. independently of whether --with-cxx was provided. That doesn't match up with reports from my testers who say they can run with C++ extension modules from many different GCC versions if they just configure their Python --without-cxx. If what you were saying were true, wouldn't --without-cxx be ignored on ELF/Linux? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On 7/11/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > You are wrong. Current string literals are explicit. They are what you > type. No they are not: >>> "I typed \x41, but got this!" 'I typed A, but got this!' What we have are not explicit string literals but *explicit rules*, forming part of the language definition and given in the documentation that certain sequences in string literals are preprocessed by the compiler. People have learnt these rules and apply them unconsciously when reading the source--but that can apply to any rule. For example, there's another explicit rule, that an "r" prefixed before the string literal uses a different set of rules without \-escape sequences: >>> r"I typed \x41, but got this!" 'I typed \\x41, but got this!' The point is that processing \-escape sequences is just as implicit as my proposal: but tradition, and custom, and documentation make it *seem* explicit of itself. IOW, arguing that my proposal is "implicit" or "DWIM" is neither relevant nor valid--but arguing either that it is confusing to a long-term Python user, or that it is not fully backward compatible is valid, and these (and other) arguments against should be weighed up against those in favour. (Even some fairly recent and major changes to Python have been accepted despite having these two particular arguments against them, such as unified classes/types and nested scopes). > When you have to start differentiating, or consider differentiating, how > preprocessing occurs based on the existance or non-existance of escaped > newlines, you should realize that this has a serious "Do what I mean" > stink (as Guido has already stated, more politely). What I am considering differentiating on here is a feature of Python that is (at least) awkward and (at most) has a "serious stink" -- the ability to escape newlines in a single-quoted [' or "] string with a backslash, which has inconsistent or confusing behaviour: >>> "This is a normal string\ ... with an escaped newline." 'This is a normal stringwith an escaped newline.' >>> r"This is a raw string\ ... with an escaped newline." 'This is a raw string\\\nwith an escaped newline.' This is not an issue with TQS's because they can naturally (i.e. without escapes) span multiple lines. Since your main objections above are much the same as Guido's, I'll respond to his in this message also: On 7/11/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > The scheme may be explicitly spelled out in the language reference, > but it is implicit to the human reader -- what you see is no longer > what you get. See discussion of explicitness vs. implicitness above. > I recommend that you give it up. You ain't gonna convince me. Very likely. But given the number of times that similar proposals have been put forth in the past, it is reasonable to expect that they will be brought up again in the future by others, if this is rejected--and in that case, these other can simply be pointed to a thorough (but rejected) PEP that discusses the proposal and variants and reasons for rejection. And so--while I still hope that you can be convinced (there's precedent ;-), I think a good, thorough PEP will be of benefit even if rejected. And, of course, such a PEP is bound to be more convincing than a hasty ill-considered one. So I am rewriting my previous draft accordingly, and will submit it as a PEP when it's done. Cheers, Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
Andrew Durdin <[EMAIL PROTECTED]> wrote: > > On 7/11/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > > > You are wrong. Current string literals are explicit. They are what you > > type. > > No they are not: Apparently my disclaimer of "except in the case of the decades-old string escapes that were inherited from C, as well as unicode and 'raw' strings" didn't make it into the final draft of that email. It is not as though you are taking something that used to be invalid and making it valid, you are taking something that used to mean X and making it mean Y. Your proposed change /will/ cause incompatibility for some unknown number of modules which rely on the indentation of triple quoted strings. You should realize that people get angry when their APIs change the meaning of f(x), and you are asking for the language to do that. Have you a guess as to why you are getting resistance? - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
On Jul 10, 2005, at 6:39 PM, Josiah Carlson wrote: > > Andrew Durdin <[EMAIL PROTECTED]> wrote: > >> >> On 7/11/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: >> >>> >>> You are wrong. Current string literals are explicit. They are >>> what you >>> type. >>> >> >> No they are not: >> > > Apparently my disclaimer of "except in the case of the decades-old > string escapes that were inherited from C, as well as unicode and > 'raw' > strings" didn't make it into the final draft of that email. > > It is not as though you are taking something that used to be > invalid and > making it valid, you are taking something that used to mean X and > making > it mean Y. Your proposed change /will/ cause incompatibility for some > unknown number of modules which rely on the indentation of triple > quoted > strings. You should realize that people get angry when their APIs > change > the meaning of f(x), and you are asking for the language to do that. > Have you a guess as to why you are getting resistance? A better proposal would probably be another string prefix that means "dedent", but I'm still not sold. doc processing software is clearly going to have to know how to dedent anyway in order to support existing code. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
"Andrew Durdin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Very likely. But given the number of times that similar proposals have > been put forth in the past, it is reasonable to expect that they will > be brought up again in the future by others, if this is rejected--and > in that case, these other can simply be pointed to a thorough (but > rejected) PEP that discusses the proposal and variants and reasons for > rejection. I agree that this would be useful. I also agree with Bob Ippolito that a new prefex might be better. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
Terry Reedy wrote: > "Andrew Durdin" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Very likely. But given the number of times that similar proposals have >> been put forth in the past, it is reasonable to expect that they will >> be brought up again in the future by others, if this is rejected--and >> in that case, these other can simply be pointed to a thorough (but >> rejected) PEP that discusses the proposal and variants and reasons for >> rejection. > > I agree that this would be useful. I also agree with Bob Ippolito that a > new prefex might be better. Why using a new syntax construct when you can do it with existing features? We do already have str.split(), which is often used to postprocess string literals (in the perl qw() style), why not introduce str.dedent()? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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 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 (alone). However, the decision to use CXX for linking is independent on whether --with-cxx was given. >>- the configure test is extended to better match current g++ >> behaviour. > > > What do you have in mind? Somebody reported that the test works better for g++ if the function is marked extern "C". This should be done for 2.4 regardless of any other change. >>I just checked, and it seems that the logic in use is still somewhat >>different. If the configure test determines that a C++ main() >>must be linked with CXX, it unconditionally changes the linker to CXX. >>The test, in turn, is run always if a C++ compiler was found, >>i.e. independently of whether --with-cxx was provided. > > > That doesn't match up with reports from my testers who say they can > run with C++ extension modules from many different GCC versions if > they just configure their Python --without-cxx. If what you were > saying were true, wouldn't --without-cxx be ignored on ELF/Linux? Ok, it's still different. I see three cases now: 1. --without-cxx or --with-cxx=no specified. configure does not look for a C++ compiler, and does not check whether linking needs to be done with a C++ compiler, and decides to use Modules/python.c. 2. --with-cxx not given. configure does look for a C++ compiler, and does check whether linking with the C++ compiler is necessary, and still uses Modules/python.c 3. --with-cxx is given. configure requires it to point to a C++ compiler, performs the linking check, and uses Modules/ccpython.cc. It would help discussion if you would use the actual code, too, instead of just using reports from your testers. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
