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

Re: package-uses-debhelper-but-lacks-build-depends ????

On Thu, Mar 16, 2006 at 02:27:13AM -0500, Yaroslav Halchenko wrote:
> Dear All,
> I am in the process of packaging a new package toward closing ITP ;-)
> and although I defined Build-Depends to depend on debhelper, lintian is
> not happy anyways.... What is my problem???
> binaries are from
> http://itanix.rutgers.edu/rumba/dists/unstable/perspect/binary-i386/science/
> sources (and diff)
> http://itanix.rutgers.edu/rumba/dists/unstable/perspect/source/science/
> package pyepl 
> lintian reports:
> E: pyepl source: package-uses-debhelper-but-lacks-build-depends
> > grep debhelper  debian/control
> Build-Depends: debhelper (>= 4.0.0), .........
I guess its because your first "stanza" (the source paragraph) doesn't
begin on the first line.

> E: python2.4-pyepl: shlib-with-non-pic-code usr/lib/python2.4/site-packages/pyepl/hardware/sound/_eplSound.so
> E: python2.3-pyepl: shlib-with-non-pic-code usr/lib/python2.3/site-packages/pyepl/hardware/sound/_eplSound.so
> and that is a mistery as well... description of shlib-with-non-pic-code
> doesn't really seem to provide an answer to what is happening -- I don't
> see those switches in Makefiles... 
> anyways probably it is time to go to bad ;-))) 
The objects which compose the shared library "must" be compiled with
-fPIC; policy 10.2:

The rationale is that some architectures require this for compilation
to succeed [0], and other archictectures experience considerable
runtime slowdown in reprocessing [1].

Static libraries mustn't be compiled with -fPIC, since there is no
relocation involved, and this would just add overhead to the code.
This requires recompiling the object files for library packages which
provide both .a and .so libs, for their -dev and runtime packages.



[0] http://bugs.debian.org/severity:serious&include=subj:fPIC
[1] http://people.redhat.com/drepper/dsohowto.pdf

Reply to: