[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy proposal: Cpu extension code, update-ldsoconf

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.


-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>

Reply to: