On Fri, Apr 14, 2006 at 02:04:34PM -0700, Keith M Wesolowski wrote: > On Fri, Apr 14, 2006 at 01:50:54PM -0700, Philip Brown wrote: > > > b) the package wants to take advantage of some kind of library or > > interface that is only availlable on solaris 10. In the free > > software world, this almost never happens; free software usually > > takes advantage of other free software, not differences between > > solaris 8 and solaris 10. > > Unfortunately this does happen. In fact, it just happened in the last > couple of weeks: Casper integrated the mkstemps family of functions > into libc. By itself, this would be uninteresting - an application or > library either requires this function or it doesn't. If it does, that > software would simply fail to work on builds which don't offer the > function.
Or, in the blastwave case, we simply build against a library that we ship ourselves, in another package. ..... > But in the other > direction, the choice to include these varied private static libraries > makes it impossible for the older software to take advantage of > improvements in the standard system libraries. The impact can range > from mere unnecessary code (if the two implementations are compatible > and equally performant) to missed performance opportunities (for > example, not using libmd5 fails to take advantage of sun4v > optimisations) to severe breakage. If there is "severe breakage", then Sun has broken its promise of binary API forward compatibility, and it is Sun's problem to fix the breakage :-) As far as sol10-optimized libraries... There are ways around this sort of thing, if the blastwave maintainers are made aware of specific performance enhancements like that sort of thing. To use your specific example, a program could be compiled against a stub or generic libmd5 which we would provide, , which would have sun's /usr/lib/libmd5.so set as an auxiliary filter. If present, sun's optimized libmd5 would be used. If not, then generic non-specifically-optimized routines would be used. We have already used this approach successfully, to compile in OpenGL support for apps that have this as a compile-time option. If a hardware accelerated libGL.so is present, that gets used; otherwise, the app drops back to software rendering in our provided libGL.so Its pretty much the same issue: A specialized library may or may not be present; if it is, take advantage of it. if not, dont. Another example, for the case of XVideo support in sol10, but not sol8: We decided to compile on sol8, but manually link against a client-side XVideo lib that we provide. It's a tiny thing; most of the work is actually done on the Xserver side. So, we get run-time optimization of our app: If it is running on sol10 with XVideo support... it uses the XVideo extension. If there is no XVideo support.. it drops back to normal use. but it still runs. Everyone wins, no-one loses.
