Camm Maguire wrote:
I think ldso already has this capability. While they were around, the glibc-i686 etc. packages took advantage of this.2) This library should be placed in a designated subdir of /usr/lib specialized for code requiring the cpu extension in question. All such directories should be agreed on and sanctioned by the policy committee. As a suggestion, the directory might be named after the cpu capability (as reported in /proc/cpuinfo) required to run the code, e.g. /usr/lib/xmm, /usr/lib/3dnowext, etc.)
The problem is that this breaks on those architectures, e.g. ARM, which can't link shared libs at all without -fPIC. You'd have to be very careful to include -fPIC with subarches on some arches and leave it out on others. It would be tricky to build such packages.looks like a good idea, but I'd like to add something to this paragraph: Libraries placed in these directories are exempted from the obligation to use the -fPIC compilation flag. The rationale is that this code has been separated only as an easy way to comply with 1), not because we actually expect to share this code with any other executables. Because this code is time-critical, it makes more sense to avoid the runtime cost associated with -fPIC here.
<digression>The real lesson here is not that -fPIC is bad, but that register-starved architectures like i386 and derivatives are inherently flawed, IIRC due to legacy compatibility issues. Maybe the -fPIC exception should only apply to such broken architectures?</digression>
Wonderful. So how should we proceed from here?
Wishlist bug report against debian-policy. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6Welcome to the best software in the world today cafe! <http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>