Interestingly, I found the following libraries on a current 'unstable' system already using 586 instructions and not installed in an appropriate subdirectory: /lib/i386-linux-gnu/libgcrypt.so.11.7.0: cpuid /usr/lib/i386-linux-gnu/i486/libcrypto.so.1.0.0: cpuid /usr/lib/i386-linux-gnu/i486/libcrypto.so.1.0.0: rdtsc /usr/lib/i386-linux-gnu/libavutil.so.51.7.0: cpuid /usr/lib/i386-linux-gnu/libavutil.so.51.7.0: rdtsc /usr/lib/i386-linux-gnu/libgcj.so.10.0.0: cmpxchg8b /usr/lib/i386-linux-gnu/libgcj.so.12.0.0: cmpxchg8b /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0.2400.0: cpuid /usr/lib/i386-linux-gnu/libgmp.so.10.0.2: cpuid /usr/lib/i386-linux-gnu/libjack.so.0.0.28: rdtsc /usr/lib/i386-linux-gnu/libmp3lame.so.0.0.0: cpuid /usr/lib/i386-linux-gnu/libpixman-1.so.0.24.0: cpuid /usr/lib/i386-linux-gnu/libvisual-0.4.so.0.0.0: cpuid /usr/lib/i486/libcrypto.so.0.9.8: cpuid /usr/lib/i486/libcrypto.so.0.9.8: rdtsc /usr/lib/libavcodec.so.52.72.2: cpuid /usr/lib/libavutil.so.50.15.1: rdtsc /usr/lib/libbabl-0.0.so.0.22.0: cpuid /usr/lib/libcrypto.so.0.9.8: cpuid /usr/lib/libcrypto++.so.9.0.0: cpuid /usr/lib/libdirectfb-1.2.so.9.0.1: cpuid /usr/lib/libdjvulibre.so.21.3.0: cpuid /usr/lib/libdv.so.4.0.3: cpuid /usr/lib/libfftw3f.so.3.2.4: cpuid /usr/lib/libfftw3f.so.3.2.4: rdtsc /usr/lib/libfftw3l.so.3.2.4: rdtsc /usr/lib/libfftw3.so.3.2.4: cpuid /usr/lib/libfftw3.so.3.2.4: rdtsc /usr/lib/libgegl-0.0.so.0.22.0: cpuid /usr/lib/libgimpbase-2.0.so.0.600.11: cpuid /usr/lib/libjavascriptcoregtk-1.0.so.0.11.0: cpuid /usr/lib/libjavascriptcoregtk-3.0.so.0.11.0: cpuid /usr/lib/libmozjs.so.6d: cpuid /usr/lib/libmozjs.so.7d: cpuid /usr/lib/libmozjs.so.8d: cpuid /usr/lib/libmpg123.so.0.25.1: cpuid /usr/lib/libmysqlclient_r.so.16.0.0: cpuid /usr/lib/libmysqlclient.so.16.0.0: cpuid /usr/lib/liborc-0.4.so.0.16.0: cpuid /usr/lib/liborc-test-0.4.so.0.16.0: rdtsc /usr/lib/libQtCore.so.4.7.3: cpuid /usr/lib/libQtScript.so.4.7.3: cpuid /usr/lib/libQtTest.so.4.7.3: rdtsc /usr/lib/libQtWebKit.so.4.8.0: cpuid /usr/lib/librpm.so.2.0.2: cpuid /usr/lib/libSDL-1.2.so.0.11.3: cpuid /usr/lib/libtheoradec.so.1.1.4: cpuid /usr/lib/libtheoraenc.so.1.1.2: cpuid /usr/lib/libtheora.so.0.3.10: cpuid /usr/lib/libvirt.so.0.9.7: cpuid /usr/lib/libvlccore.so.4.0.3: cpuid /usr/lib/libvpx.so.0.9.7: cpuid Use of CPUID is probably safe in practice since most 486 models do implement it, though userland should really read /proc/cpuinfo. The other uses may be conditional on a CPU feature test but may well be bugs. Also, the following are using CMOV: /usr/lib/i386-linux-gnu/libasound.so.2.0.0: cmov /usr/lib/i386-linux-gnu/libavcodec.so.53.5.0: cmov /usr/lib/i386-linux-gnu/libgmp.so.10.0.2: cmov /usr/lib/libcrypto++.so.9.0.0: cmov /usr/lib/libmysqlclient_r.so.16.0.0: cmov /usr/lib/libmysqlclient.so.16.0.0: cmov - These all have run-time checks. /usr/lib/i386-linux-gnu/libpixman-1.so.0.24.0: cmov - This either has a run-time check or fails to use the optimised code at all (I don't see how it's reachable). /usr/lib/libgegl-0.0.so.0.22.0: cmov - This seems to be a bug; gegl has been compiled with -mmmx -msse and the latter option implies CMOV can be used since all processors with SSE also have CMOV. /usr/lib/libQtGui.so.4.7.3: cmov - I didn't feel like downloading the source, so haven't checked this. /usr/lib/libxenstore.so.3.0.0: cmov - The hypervisor itself requires a 686-class processor, so not a serious problem. Would it be worth adding a lintian check for instructions that may not be supported (bearing in mind that a fair few packages will need to override it)? Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'
Attachment:
signature.asc
Description: This is a digitally signed message part