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

[Justin Pryzby <justinpryzby@users.sourceforge.net>]

I was hoping that someone else would respond to this, since I'm just
fumbling for an answer.  Maybe I can provoke one:)

On Fri, Mar 18, 2005 at 12:02:34PM -0500, Kevin B. McCarty wrote:
> 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?
Maybe.  Another solution is to link it with -lc.  To be sure, the
*proper* solution is to link it with everything it needs, and nothing
more.

I'm not entirely sure how to do that; but the following options to ld
may be relevant.

  --no-undefined
  --no-allow-shlib-undefined
  --unresolved-symbols=report-all

But, rethinking this, what kind of file is that (as given by
/usr/bin/file)?  AFAIK object files (traditionally *.o) cannot be
linked with anything; indeed, gcc -lfoo -c -o bar.o baz.c yields:

  gcc: -lc: linker input file unused because linking not done

lin{da,tian} shouldn't complain about an object file which is not
linked with anything, since, well, it cannot be.  But, if it is a
shared object, which is called .o (instead of the conventional .so),
then the complaint might be warrented. 

If it is a shared object, and it actually doesn't use any external
symbols (including those from libc), then I suppose an override is
appropriate.  (Let me guess; some awkward physics software whose
authors decided to rewrite everything from the ground up using only
loops and arithmetic?  sigh.)

A line of code is worth more:

test.c: main(){}
wxyz.c: f(){ g(); }

$ gcc -shared -o libwxyz.so wxyz.c

$ gcc -Wl,--no-undefined -Wl,--no-allow-shlib-undefined -Wl,--unresolved-symbols=report-all -L.  -lwxyz test.c
./libwxyz.so: undefined reference to `g'
collect2: ld returned 1 exit status

$ gcc  -L. -lwxyz test.c
./libwxyz.so: undefined reference to `g'
collect2: ld returned 1 exit status

$ gcc -Wl,--unresolved-symbols=ignore-in-shared-libs  -L. -lwxyz test.c

$

So, it looks like your job is done when all the libraries can be
successfully linked into minimal programs (wxyz.c) without ignoring
unresolved syms.  I would recommend passing the above options to ld to
be sure (especially --no-allow-shlib-undefined, which is apparently
not the default).

Justin