Re: Package maintenance ideas
On Friday, 12 Sep, Christopher C. Chimelis wrote:
> I've tried using the __ALPHA__ define as an #ifdef condition,
> but found out that it's also defined for Digital UNIX, which can yield
> some unwanted results sometimes (that's why "man" was kinda broken for
The standard way is to test __alpha__ (e.g., see the kernel sources).
Note that Digital UNIX uses __alpha instead. By the way, I tried to test
__ALPHA__ under Linux and found it undefined.
> Secondly, it's becoming obvious to me that autodetection of architectures
> may be beneficial in debian/rules files if a configure script isn't being
> executed during the build process. Alot of fixes that I have done involve
> commenting out "-m486" switches which, although we need to do them, are
> not optimal for cross-platform optimisation compatibility.
If I remember correctly the policy document, it sais to use -O2 and not to
set the flags just for the sake of it. -m486 was not amongst recommended
flags, and I suspect there is no harm in omitting it even on Intel
platforms. Anyway, autodetection is important. For example, some
time-critical application raise optimisation level above 2, which may
cause slower (!) execution on Alphas. So we may want to set -O4 on
Intel and -O2 on an Alpha.
On Friday, 12 Sep, Bdale Garbee wrote:
> Please be *very* careful to distinguish between libc6 issues, 64-bit issues,
> and truly Alpha-specific issues... otherwise we're just making more work for
> everyone involved!
True. Just a comment: if a broken code is detected which assumes that long is
32 bit wide, probably the right way to fix it is to use glibc's int32_t and
u_int32_t types rather than changing long to int. (Certainly
long/pointer size problems should not be solved by testing __alpha__...)
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
firstname.lastname@example.org . Trouble?
e-mail to email@example.com .