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

Re: Including object (.o) files in a package - linda errors

"Kevin B. McCarty" <kmccarty@Princeton.EDU> writes:

> Hi list,
> I am packaging mn_fit (source package is named mn-fit; currently stuck
> in NEW).  Upstream tells me that the capability exists for users to
> create a customized version of mn_fit by linking their own Fortran
> source code with mn_fit static libraries and the mn_fit main object
> file, mn_main_k.o.  So I am creating a new mn-fit-dev binary package to
> contain these libraries, etc.  (Thus, users who don't need to customize
> mn_fit can just install the mn-fit binary package, without the
> additional 3 Mb of static libs in mn-fit-dev.)
> The problem is that linda really doesn't like the object file:
>> arcturus[6]:~/Debian/mn-fit% linda -i mn-fit-dev_5.05-1_powerpc.deb
>> E: mn-fit-dev; Object /usr/lib/mn-fit/obj/programs/mn_main_k.o is not directly linked against libc.
>>  The binary object shown above is not directly linked against the
>>  required library libc.so.6.
>> W: mn-fit-dev; Shared binary object /usr/lib/mn-fit/obj/programs/mn_main_k.o has no dependancy information.
>>  The binary object listed above is a shared object, but does not report
>>  that it depends on any other shared libraries.
> What can I do about this?  I found that linda gives the same complaints
> about libcrt1.o (and other object files) in the libc6-dev package.
> (Lintian doesn't care.)  Should I just add linda overrides to ignore the
> error and warning?
> thanks in advance,
> -- 
> Kevin B. McCarty <kmccarty@princeton.edu>   Physics Department
> WWW: http://www.princeton.edu/~kmccarty/    Princeton University
> GPG public key ID: 4F83C751                 Princeton, NJ 08544

You can override the lintian warnings for one thing. I don't think you
can do anything else about the libc error. You could add a shlibs
entry for the later but that would be wrong imho.

So I would just override them both.


Reply to: