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

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
> awhile).

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
debian-alpha-request@lists.debian.org . Trouble? 
e-mail to templin@bucknell.edu .

Reply to: