Re: Policy proposal: Cpu extension code, update-ldsoconf
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.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!