The lack of a 64 bit compiler able to compile to a 64bit sparc version 9b instruction set is really, really, really, really pissing me and hundreds if not thousands of other people off.
The versions of gcc available in the current stable is lacking this MUCH NEEDED SUPPORT and since all you have to do is read the documentation and use the correct host in your configure of gcc I really see no reason why such idiocy needs to continue. The development tools available for linux in any distribution are the lifeblood of the open source community surrounding it. Without the correct tools I as a developer and my fellow porting brethren do not have the ability to continue the effort. The lack of correctly compiled packages to take advantage of the added speed and power of the additional instruction sets Ultrasparc cpu�s are able to use is severely hindering the development effort in the support of not only the hardware in question, but the development community surrounding it. I understand the need to support the 'sparclite' type of low power (When compared to a ultrasparc cpu) cpu but I really firmly believe the option of having available packages compiled for this support with the default of at least the version 8 instruction set should be available if they are not already due to the sheer power gained in taking advantage of the increased instruction set. SSH is a perfect example of this as anyone with a ultrasparc system running a ssh server using debian stable is familiar with. The very slow exaction times brought on by the current package build system that does not take advantage of the hardware and as such users are forced to wait as long at 3 extra seconds as the libs compiled for the version 7 instruction set have to generate and authenticate its key. While this instruction set is clearly ABLE to do it, it is NOT the best way. The lack of these tools is also hindering porting efforts and keeping the available packages small. My own efforts as a Asterisk (A gpl PBX system) developer and my own private goal of porting it to sparc based systems has only been halfway successful due to this lack. While I have been able to get the application itself working on my sparc based system I remain unable to finish the job by finishing the kernel modules for its supporting hardware. The current development environment is not only incomplete but incompatible without allot of work that in my recent (yesterday) experience breaks the system. All we as a community need is the development tools with new enough versions numbers compiled with the correct support. Even if only as optional alternative packages. Once we have that things will take off. So please don't BREAK debian for sparc64 platforms by leaving us out when the time comes. Create and include official packages for the next release unlike you did the current release. Not including what we developers need only hurts the debian community. - D
