Camm Maguire wrote:
>>>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.)
>>>
I think ldso already has this capability. While they were around, the
glibc-i686 etc. packages took advantage of this.
>>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.
>>
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.
<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 E4B6
Welcome to the best software in the world today cafe!
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
