404 not found on for Python 2.6 Itanium

[csgrimes1]

Anyone know where else I can download 2.6 for x64 windows?

Thanks!

 

[nadiasvertex]

Then why is there a link on the download site? You are saying that
for python 2.6 forward, there is no plan to support a stock python for
IA64? Is there any particular reason why this is so?

-={C}=-

 

[Martin v. Löwis]

Then why is there a link on the download site?

Where specifically did you spot that link? I can't see any.

You are saying that
for python 2.6 forward, there is no plan to support a stock python for
IA64? Is there any particular reason why this is so?

Yes. It's too much effort to build, and too few users that actually
use it. Users are still free to build it themselves, and to share
the build with others.

Regards,
Martin

 

[Jerry Hill]

Where specifically did you spot that link? I can't see any.

I believe the link in question is on the page
http://www.python.org/download/ titled "Python 2.6 Windows Itanium
installer" with a link to
http://www.python.org/ftp/python/2.6/python-2.6.ia64.msi . Clicking
on that link brings you to a 404 error page. There is no Itanium
install linked from the 2.6 release page
(http://www.python.org/download/releases/2.6/)

 

[Martin v. Löwis]

Copied from the download page:

It would have helped if you had provided the URL instead. I didn't
recognize that you were talking about

http://www.python.org/download/

as I rarely ever view this page. On

http://www.python.org/download/releases/2.6/

no such link is included.

I have now deleted the link; thanks for pointing this problem out.

In any case, if you want Itanium binaries of Python, I recommend to
use 2.5.2, from

http://www.python.org/download/releases/2.5.2/

Regards,
Martin

 

[Terry Reedy]

I believe the link in question is on the page
http://www.python.org/download/ titled "Python 2.6 Windows Itanium
installer" with a link to
http://www.python.org/ftp/python/2.6/python-2.6.ia64.msi . Clicking
on that link brings you to a 404 error page.

That appears to have been fixed, by removing the erroneous link.


There is no Itanium

 

[Christopher]

Yes. It's too much effort to build, and too few users that actually
use it. Users are still free to build it themselves, and to share
the build with others.

I guess that I don't understand why you feel there is so much effort
involved. I developed a set of makefiles that build Python and all
dependencies from the command line using nmake. The only thing you
have to do is specify debug and cpu. The rest is taken care of by the
Makefiles. Of course, this dev setup uses VS 2005, but it could be
made to work with VS 2008 with little trouble. The setup is designed
to cross compile the x64 and ia64 architectures.


-={C}=-

 

[Steve Holden]

[Martin von Loewis wrote]:

Yes. It's too much effort to build, and too few users that actually
use it. Users are still free to build it themselves, and to share
the build with others.

I guess that I don't understand why you feel there is so much effort
involved. I developed a set of makefiles that build Python and all
dependencies from the command line using nmake. The only thing you
have to do is specify debug and cpu. The rest is taken care of by the
Makefiles. Of course, this dev setup uses VS 2005, but it could be
made to work with VS 2008 with little trouble. The setup is designed
to cross compile the x64 and ia64 architectures.

Among other things it's a question of

a) access to resources (we have to test what we release), and

b) volunteer effort to maintain (we have to maintain what we release).

We are fairly weak in the Windows area, and Martin is currently the
person we rely on for these builds. If he can't support them, they don't
get built.

If you want to stand up for the task I don't imagine it would be too
difficult to submit patches for the Itanium builds. You would need to
convince people about your intention of providing long-term support,
however.

regards
Steve

 

[Steve Holden]

[Martin von Loewis wrote]:

Yes. It's too much effort to build, and too few users that actually
use it. Users are still free to build it themselves, and to share
the build with others.

I guess that I don't understand why you feel there is so much effort
involved. I developed a set of makefiles that build Python and all
dependencies from the command line using nmake. The only thing you
have to do is specify debug and cpu. The rest is taken care of by the
Makefiles. Of course, this dev setup uses VS 2005, but it could be
made to work with VS 2008 with little trouble. The setup is designed
to cross compile the x64 and ia64 architectures.

Among other things it's a question of

a) access to resources (we have to test what we release), and

b) volunteer effort to maintain (we have to maintain what we release).

We are fairly weak in the Windows area, and Martin is currently the
person we rely on for these builds. If he can't support them, they don't
get built.

If you want to stand up for the task I don't imagine it would be too
difficult to submit patches for the Itanium builds. You would need to
convince people about your intention of providing long-term support,
however.

regards
Steve

 

[Christopher Nelson]

I'm not sure what to say about that. The company I work for is
committed to Python (our product is mostly Python source), and my
current job is to make our software work on Itanium, which means
providing an Itanium build of Python. As long as I have this job I
suspect that I will be maintaining it. However, "maintaining" it for
us means that I deliver a set of binaries and build system
integration. My buildsystem changes are a significant departure from
the way Python currently builds.

Since Python 2.6 actually supports a decent windows compiler, it may
be easier for me to provide the various platform binaries (assuming we
go to Python 2.6 in the next year or so) within the stock python build
framework. (Which mostly means patches that the community might
actually find useful. My current build framework targets Python 2.4
on VS2K5, which is probably of little use to anyone.)

In any case, my concern with dropping a stock python itanium distro
involves the vastly diminished probability that others will provide
Itanium versions of, for example py2exe and pywin32.

I would certainly be willing to help with testing and building and
bug fixing to the extent that my secular job allows it.

 

[Martin v. Löwis]

I guess that I don't understand why you feel there is so much effort

involved. I developed a set of makefiles that build Python and all
dependencies from the command line using nmake. The only thing you
have to do is specify debug and cpu. The rest is taken care of by the
Makefiles. Of course, this dev setup uses VS 2005, but it could be
made to work with VS 2008 with little trouble. The setup is designed
to cross compile the x64 and ia64 architectures.

It starts with the need for the hardware. My only Itanium 1 system left
is old and about to crash any day now, and it doesn't support debugging
quite at all. Even if it was new and fast, I still would need to log
into that machine, download the installer, and run it - preferably in
multiple combinations (of, say, Windows 2003 and Windows 2008, with
and without the VS 2008 CRT installed).

In any case, I wouldn't be using makefiles, but adjust the project files
of VS 2008 to invoke the Itanium compiler (for which I would first have
to find out where to get it).

There is also one serious problem with cross-compilation: Tcl/Tk
doesn't support it well. In particular, Tcl 8.5 tries to run the
resulting Tcl interpreter to generate timezone data, which fails.
I had to hack the makefile temporarily to get around that (for AMD64),
but it's not pretty.

A minor problem with cross-compilation is that it doesn't work well
for PGO builds.

Regards,
Martin

 

[Martin v. Löwis]

In any case, my concern with dropping a stock python itanium distro

involves the vastly diminished probability that others will provide
Itanium versions of, for example py2exe and pywin32.

Well, I had been providing Itanium binaries for 2.4 and 2.5, and neither
py2exe nor pywin32 ever emerged.

It *is* fairly unlikely that the community will provide Itanium support
for anything, as nobody really has the hardware to run it on. So if you
are using Itanium, you will have to do all the porting yourself.

I would certainly be willing to help with testing and building and
bug fixing to the extent that my secular job allows it.

If you start providing binaries, we would be happy to link to them
from the release pages (provided they arrive within some reasonable
time after the release, otherwise, the link would go off the download
page, or the windows page).

I have personally given up with Windows on Itanium - it just isn't
worth my time. We do have new Itanium hardware, but we run VMS and
HP-UX on it. Why would anybody run Windows on Itanium? You can't
get any games for it

For some time, there was interest in Python for AlphaNT, and that
interest has died away also. It seems that even Microsoft has lost
interest in Itanium as a Windows platform - they never released
Office for it, for example, and Windows 2008 on Itanium is also
crippled.

Regards,
Martin

 

[r0g]

Well, I had been providing Itanium binaries for 2.4 and 2.5, and neither
py2exe nor pywin32 ever emerged.

It *is* fairly unlikely that the community will provide Itanium support
for anything, as nobody really has the hardware to run it on. So if you
are using Itanium, you will have to do all the porting yourself.


If you start providing binaries, we would be happy to link to them
from the release pages (provided they arrive within some reasonable
time after the release, otherwise, the link would go off the download
page, or the windows page).

I have personally given up with Windows on Itanium - it just isn't
worth my time. We do have new Itanium hardware, but we run VMS and
HP-UX on it. Why would anybody run Windows on Itanium? You can't
get any games for it

For some time, there was interest in Python for AlphaNT, and that
interest has died away also. It seems that even Microsoft has lost
interest in Itanium as a Windows platform - they never released
Office for it, for example, and Windows 2008 on Itanium is also
crippled.

Regards,
Martin

If you can't get the compile working could you maybe try using a pure
python implementation of the ctypes module, say the one from pypy?

Roger.

 

[Terry Reedy]

I guess that I don't understand why you feel there is so much effort
involved. I developed a set of makefiles that build Python and all
dependencies from the command line using nmake. The only thing you
have to do is specify debug and cpu. The rest is taken care of by the
Makefiles. Of course, this dev setup uses VS 2005, but it could be
made to work with VS 2008 with little trouble. The setup is designed
to cross compile the x64 and ia64 architectures.

Martin builds two tested installer/uninstallers that work on nt, xp, and
vista and include IDLE and docs as Microsoft Help files. The 2.6 doc
change apparently required changes in the doc build, and 3.0 changes
changed something about IDLE. To me, that seems enough for one volunteer.

tjr

 

[Christopher]

If you can't get the compile working could you maybe try using a pure
python implementation of the ctypes module, say the one from pypy?

Roger.

No. I am using ctypes to access Windows .dll functions primarily. I
didn't want to have to write a native code module b/c it's such a
hassle and cytpes works so well.

-={C}=-

 

[Christopher]

Martin builds two tested installer/uninstallers that work on nt, xp, and
vista and include IDLE and docs as Microsoft Help files.  The 2.6 doc
change apparently required changes in the doc build, and 3.0 changes
changed something about IDLE.  To me, that seems enough for one volunteer.

tjr

No criticism was intended. It was merely an RFI.

-={C}=-

 

[Martin v. Löwis]

No criticism was intended. It was merely an RFI.

Not sure whether you got the answer you wanted - when I said
"it is too much effort to build (and too few users)", I really
meant "it is non-zero effort, which is too much".

Regards,
Martin