Re: Including object (.o) files in a package - linda errors
Hi Justin,
Justin Pryzby wrote:
> 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:
>> > 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.
> 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
Yep, it's just a normal object file, originally compiled with something
like "g77 -c -o mn_main_k.o mn_main_k.f". The intent of the author is
to let people build in their own functionality to the program (mn_fit)
by linking this object file, the mn_fit static libraries, and their own
custom code into a custom executable.
In principle I guess there is no reason I can't include the source code
mn_main_k.f into the mn-fit-dev package, instead of the object file, and
make sure it gets built correctly when the user wants to compile. Maybe
I'll do that in the next upload as the easiest way to get around the
whole issue.
> lin{da,tian} shouldn't complain about an object file which is not
> linked with anything, since, well, it cannot be.
OK, I will file a bug against linda then. (any objections?)
[I snipped the rest of your analysis which maybe isn't relevant to this
specific case, but it looks like helpful advice in general.]
> 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.)
Almost as bad: it's based on Cernlib so it's likely completely br0ken on
64-bit. I could probably get around the FTBFSes on alpha and ia64, but
the resulting binary probably wouldn't work anyway, so I won't try
before the Sarge release. :-(
regards,
--
Kevin B. McCarty <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544
Reply to: