[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Lack of 64 bit support in devel tools for stable, current and future.



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





Reply to: