Bug#329762: Relaxation and documentation of the "-fPIC" constraint

[Manoj Srivastava <srivasta@debian.org>]

severity 329762 wishlist
retitle 329762  [DISCUSS] documentation of the "-fPIC" constraint
thanks

Hi,

        This discussion is very incomplete, with large chunks of
 information missing. Let us see if I have a correct summary:

  If you are using gcc,  -fPIC produces code with relocatable position
  independent code, which is required for most architectures to
  create a shared library, with i386 and perhaps some others where non
  position independent code is permitted in a shared library.

  Shared libraries reduce RAM used, and so are good things, and in any
  case, policy is talking about what to do when creating shared or
  static libs, so why to use shared libs is out of scope here.

  Position independent code may have s performance penalty, especially
  on i386. However, in most cases the speed penalty must be measured
  against the memory wasted on the few architectures where non
  position independent code is even possible.

  If the package is architecture: any, then share library compilation
  and linking flags must have -fPIC, or the package shall not build on
  some of the supported architectures.

  So, I think policy should say share libraries MUST be built with
  -fPIC, unless discussed on -devel (for instance, if the library
  contains hand crafted assemly code that is not relocatable, the
  speed penalty is excessive for compute intensive libs [must be
  special cased code for some arches, of course]), and a consensus
  must be sought.

  As to the static libraries, the common case is not to have
  relocatable code, since there is no benefit, unless in specific
  cases; (need a Perl API to a library rapidly changing so shared
  libraries are pointless, used for mklibs in d-i, etc). Not so sure a
  discussion/consensus are warranted here, but documenting this
  prominently should be required.


        manoj
-- 
A real friend isn't someone you use once and then throw away. A real
friend is someone you can use over and over again.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C