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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
