At the risk of overstating the obvious, there are also ABI guarantees at stake here, which in my mind are architecture agnostic. OpenGL applications need to know which bits (API functions) of which core versions can be expected to be resolved during load time and which must be queried through GetProcAddress. LSB specifies this and makes it unambiguous.
cheers, Jesse
On Wed, Jun 1, 2011 at 8:00 AM, Jeff Licquia jeff@licquia.org wrote:
On 06/01/2011 07:25 AM, Luke Kenneth Casson Leighton wrote:
so in _that_ regard, the question becomes: "are the efforts of the free software community better off being spent elsewhere"? and "what benefit is there *TO THE FREE SOFTWARE COMMUNITY* of doing LSB for ARM"? forget the proprietary junkies, they'll suck anything from us that moves and not give a dime in return.
That seems to be my cue to provide the community case for the LSB.
The LSB provides several things to the community:
- a framework for allowing Linux distributions to pool their userbase and work together as one platform instead of multiple platforms, one per distro
- test suites which identifies both compatibility problems and outright bugs to be detected and fixed
- a method for targeting builds at multiple distributions at once, both proprietary and free
- reporting tools for finding portability problems in built apps, again for both proprietary and free apps
We currently provide all of this for 7 architectures. ARM benefits indirectly (for example, many of the compatibility breaks detected on, say, x86_64 will affect all archs equally), but indirect support doesn't include the tools we've developed, and often compatibility issues are arch-specific.
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev