On Wed, Jan 28, 2009 at 11:17:27AM -0000, Catalin Marinas wrote: > On Thu, 2009-01-22 at 15:58 +0000, Loïc Minier wrote: > > Concerning libm as a candidate for opts: libm is in libc which is > > definitely a candidate for an optimized version; for example with have > > an i686 version for the i386 arch which provides an alternate libm: > > http://packages.ubuntu.com/jaunty/i386/libc6-i686/filelist > > Could we not have the same for other packages that would benefit from > VFP? I'm not too familiar with the version conflicts in the .deb > packages but, for example, could we have something like a dummy > openoffice package which depends on either openoffice-softfp or > openoffice-vfp?
OpenOffice.org's packaging is already very complex, consisting of 57 binary packages with complex dependencies both among its own packages and between them and others. I think it is unlikely that adding FP variants of many of those with different binary package names would successfully meet anyone's requirements. Even elsewhere, this approach is fraught with practical problems. We can take this approach successfully with glibc, but glibc is a very special case. We can cope with having libc6-i686, libc6-sparcv9, and the like because libc6 is always installed and essentially never changes its SONAME, and so the installer can include special-case code to make sure that optimised variants of it are installed; we can easily extend that code for ARM, and I expect it will make sense to do so. This isn't something we can generalise in any straightforward way, though. The package management system used on the system after installation (i.e. dpkg, apt, and friends) doesn't know how to identify and select packages appropriate for variants of a particular architecture, and so there would be no way to guarantee that the proper optimised packages get installed when a user asks for the dummy name. (Attempting to add this feature would run into a number of interesting and long-standing roadblocks such as the lack of versioned Provides, and I suspect would start to approach "multiarch", which is a huge and somewhat technically-controversial project.) This problem applies to separate binary packages, but not to hwcap optimisations in general, of course. As long as hwcap works (whether in the runtime linker or a similar implementation elsewhere, e.g. GStreamer), we can just put the optimised objects in the same package as the unoptimised ones, as long as there aren't too many variants and you don't mind the binary package size growing a bit. Since I understand that we aren't likely to be supporting normal CD images for ARM, this isn't as much of a problem as it would be for other architectures. (OOo itself might still be a problem due to sheer size and the utter horribleness of its build system, but I assume you meant it more as an example than as an initial target!) -- armel gcc default optimisations https://bugs.launchpad.net/bugs/303232 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
