Re: [Python-Dev] HP-UX clean-up
------------------- Message from Skip Montanaro --------------------
Andrew> My lack of experience with configure make it hard to submit a Andrew> patch, so I'll ask python-dev first.
That's okay. What you gave is a good start. I have a couple questions though:
1. How can I distinguish the three processors you described (HP/RISC 32-bit, HP/RISC 64-bit, HP/ITANIUM 64-bit)? I suspect uname might be the culprit. If so, can you provide uname output for the three processors?
2. Is there no way to actually create a truly processor-independent executable (perhaps by creating a "fat" binary)?
Thx,
Skip
_______________________________________________ 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/mon%40abaqus.com --------------------------------------------------------
Would not it be better if you let the users (people who compile Python) decide what they want? There are several reasons for this: 1) It is hard (== unreliable) to try to distinguish them using 'model', etc.; 2) Reliance on such techniques will inevitably break overtime when the new processor denominations come into play; 3) Most importantly, it is possible to be on the 64-bit machine and be purposefully compiling for a 32-bit processor (to cover the broadest customer base). It is also possible to be on RISC and compile for ITANIUM and vice versa, because it is the same compiler. Moreover, ITANIUM machines will run RISC binaries. In other words, the confusion never stops ... People, on the other hand, usually know what machine they are working on now, and what machine they want Python to work on after they built it. There will be less surprises for them of the sort "Oh, that what happened during the compilation!... I had not idea ..." after the fact that you built this, distributed it to somebody, and had report back that it all failed. Maybe there should also be some sort of option for expects who will not want Python to be compiled for generic processor; who might purposefully want to compile Python on their particular hardware and have it fully optimized for it to gain maximum performance. Thank you, -- Nick Monyatovsky -- mon@abaqus.com
"Nick Monyatovsky" <mon@ABAQUS.com> writes:
Would not it be better if you let the users (people who compile Python) decide what they want?
I believe the idea is to cater for people wanting to produce binary distributions of Python. For such people, the fewer variations they need, the better. I would be very happy to get a binary distribution of Python for HPUX, as I regularly work on HPUX machines which don't have compilers. <rant> I've a particular bee in my bonnet about HP machines, though, as I tend to work via telnet/SSH only, no X, on boxes with almost no optional extras installed. I'm sick of finding distributions of Vim which require X libraries installed, even though I'm not going to use the X features. And need to be root to install, although I only want the *(&^&*@#$ thing for my own use! </rant> Sorry about that... Paul. -- This signature intentionally left blank
Nick Monyatovsky wrote:
Would not it be better if you let the users (people who compile Python) decide what they want?
No, not at all. configure should always give a working installation if invoked without options. If we have to make decisions for people to obtain such a working installation - fine. We then have to ask whether people might have made different decisions, and whether we want to support them in that decision. In many cases, we found that not giving choices is the right thing. So, for your set of options: 1. configure should find out automatically how to enable large file support on a 32-bit machine. In fact, there is code in configure.in to automatically detect LFS. I'm surprised that you are specifying LFS on the command line - this should not be necessary. 2. Assuming -Wl,+s -Wl,+k are warnings: We would turn them on if they are always acceptable, and leave them off if there are cases were they are not applicable. Figuring out whether warning options are needed/possible is too much effort, letting the user make the choice is pointless - our other compilers give plenty of warnings, so I believe that the HP compiler's complaints are likely false positives or otherwise irrelevant. 3. We would compile/link with threads always if possible, unless --disable-threads was given. If compiled with threads, configure should know to pass -lpthread. 4. On the model selection options, I don't quite understand why you say that this set of options gives portable binaries. I would have thought that +DA1.1 +DS2.0 is the set of option that gives portable binaries. Of course, if we can assume all hardware is PA 2.0 meanwhile, this would be fine. In that case, we would always add the PA 2.0 option set, leaving the user no choice.
1) It is hard (== unreliable) to try to distinguish them using 'model', etc.;
Then there should be no choice at all.
2) Reliance on such techniques will inevitably break overtime when the new processor denominations come into play;
Then there should be as few options as possible, assuming that the compiler defaults will do the right thing, anyway (which appears to be the case with respect to model selection).
3) Most importantly, it is possible to be on the 64-bit machine and be purposefully compiling for a 32-bit processor (to cover the broadest customer base). It is also possible to be on RISC and compile for ITANIUM and vice versa, because it is the same compiler. Moreover, ITANIUM machines will run RISC binaries.
I don't think it should be directly supported. By default, configure should force PA binaries on PA hardware, and Itanium binaries on Itanium hardware. One issue is whether we should produce 32-bit or 64-bit binaries on PA 2.0 machines by default; I don't know which one is more reasonable. Switching to the other one should be as simple as setting CC before invoking configure (this is how it works on Solaris).
People, on the other hand, usually know what machine they are working on now, and what machine they want Python to work on after they built it.
People should be able to specify things that they reasonably should be able to specify. If they don't specify anything, something reasonable should still happen.
Maybe there should also be some sort of option for expects who will not want Python to be compiled for generic processor; who might purposefully want to compile Python on their particular hardware and have it fully optimized for it to gain maximum performance.
No, no, no. If you want to highly tune your build, you are expected to edit the makefile. Providing an explicit option for that will place a burden on users who are not able to answer difficult build questions (and, trust me, this is the majority of the users). Regards, Martin
Martin> 2. Assuming -Wl,+s -Wl,+k are warnings: ... They cause the +s and +k options to be passed to the linker. They could also be written as -Wl,+s,+k. Martin> 4. On the model selection options, I don't quite understand Martin> why you say that this set of options gives portable binaries. Martin> I would have thought that +DA1.1 +DS2.0 is the set of option Martin> that gives portable binaries. I found an HP-UX machine I could log into which has aCC installed. It's just a 10.20 machine. HP's are on the way out here. I didn't found any running HP-UX 11. About +DA and +DS the aCC man page has this to say: +DAarchitecture Generate code for a particular version of the PA- RISC architecture specified. Also specifies which version of the HP-UX math library to link when you have specified -lm. Note Object code generated for PA-RISC 2.0 will not execute on PA-RISC 1.1 systems. To generate code compatible across PA-RISC 1.1 and 2.0 workstations and servers, use the +DAportable option. For best performance use +DA with the model number or architecture where you plan to execute the program. See the file /opt/langtools/lib/sched.models for a list of model numbers and their PA-RISC architecture designations. If you do not specify this option, the default object code generated is determined automatically as that of the machine on which you compile. Examples +DA1.1 +DA867 +DA2.0 +DAportable The first two examples generate code for the PA- RISC 1.1 architecture. The third example generates code for the PA-RISC 2.0 architecture. The fourth example generates code compatible across PA-RISC 1.1 and 2.0 workstations and servers. +DSmodel Use the instruction scheduler tuned to the model specified. If this option is not used, the compiler uses the instruction scheduler for the architecture on which the program is compiled. The architecture is determined by uname() (see uname(2)). model can be a model number, PA-RISC architecture designation or PA-RISC processor name. See the file /opt/langtools/lib/sched.models for a list of model numbers and processor names. Obviously, due to the age of the OS on this machine, there's no mention of Itanium. >> Maybe there should also be some sort of option for expects who will >> not want Python to be compiled for generic processor; who might >> purposefully want to compile Python on their particular hardware and >> have it fully optimized for it to gain maximum performance. Martin> No, no, no. If you want to highly tune your build, you are Martin> expected to edit the makefile. Providing an explicit option for Martin> that will place a burden on users who are not able to answer Martin> difficult build questions (and, trust me, this is the majority Martin> of the users). It would also make the configure script that much more fragile. Skip
participants (4)
-
Martin v. Loewis -
Nick Monyatovsky -
Paul Moore -
Skip Montanaro