On Sat, 26 Jul 2008 18:54:20 +0200 Arfrever Frehtes Taifersar Arahesis <[EMAIL PROTECTED]> wrote: > Respecting LDFLAGS provides also some some degree of optimization.
It's a *very* small degree, and certainly nowhere near on the scale of the difference made by CFLAGS on some archs. If CFLAGS only made the kind of difference that it made on x86 on other archs, packages ignoring CFLAGS wouldn't be considered a big deal. It's only because ignoring CFLAGS results in either certain types of performance-critical code being *a factor of ten* slower or binaries that won't run that it matters. (As to why you get that factor of ten: gcc on sparc builds v7 code unless you tell it not to. v7 has no hardware integer multiply or divide, and doing it manually takes something like twenty clock cycles. v9 and later, which is what nearly everyone uses, has hardware integer multiply and divide, and can have several scheduled at the same time. For crypto, this matters a hell of a lot.) (And the breakage? Some archs need to be told to use IEEE floating point via a -m CFLAG, or they'll generate code using the wrong ABI.) > Potential benefits of LDFLAGS are sufficient to fix packages which > ignore LDFLAGS. The difference in impact is irrelevant, because even > bugs without any impact can be filed and should be fixed. Of all the things people could be doing, making packages honour LDFLAGS is an extremely minor issue at best. Whilst there's nothing wrong with making the changes, it's not exactly the most productive use of limited resources... -- Ciaran McCreesh
signature.asc
Description: PGP signature
