On Wednesday 25 May 2011 15:18:57 Andrew Stubbs wrote: > Never ascribe to malice that which can be adequately explained by > incompetence! I forgot who said (something like) that, but it's > certainly true in programming.
:) sure. Just checking what you meant by your previous statement. > I know I've done things the lazy way, or misunderstood how to use things > enough times myself, so I'm not going to trust others to be perfect. Yeah, I agree with that. But with that argument you can basically shoot down any progress, because somebody might not be able to understand and apply it correctly. That's why I asked whether you can come up with an example of how the availability of a macro, which identifies the distribution, could lead to additional bugs. I just can't come up with anything. > The code is frozen for anything but bug fixes, and even those have to be > serious ones, I think. Adding a macro to a header is probably OK > (Matthias?), but updating to 4.5.3 is out of the question. Yeah, well. It's something I have never really understood about distributions. Upstream can be as throrough as they want in doing only bug-fixes in their patchlevel releases. Still there's this rule that the version number in released distributions may not change, even if it's all bug-fixes. So distribution users have to wait for the next distribution version for a fix (and new bugs: because often the minor or major version changed in the meantime) or use unsupported packages/compile from sources. > I could add some sort of identifier to Linaro GCC, and Ubuntu GCC would > pick that up. > > But, so would half a dozen other distros (mostly embedded, I think). > Each then add their own patches on top of that, potentially. These > patches will fix bugs, add features, add bugs, and change random things > to taste. > > Does the Linaro identifier now mean anything? No, no more so than the > GNU macros are working for you now. Understood. But then I'd just call this badly implemented. Every release (i.e. an update of a package is a new release; a different architecture OTOH is not a different release, because it's a well-defined difference) needs to be able to identify itself in some way. Concrete ideas: __GNUC_DISTRIBUTOR__: "Ubuntu" __GNUC_DISTRIBUTOR_VERSION__: "1104" __GNUC_DISTRIBUTOR_PATCHLEVEL__: "8" Those macros ideally would become part of GCC proper and the values be settable via configure switches. I believe this scheme would solve all my problems and be understandable enough to both packagers and developers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/780551 Title: incorrect interface in avxintrin.h -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
