Re: help with lintian issues
On Tue, 2002-08-27 at 21:18, Josip Rodin wrote:
>
> Please remember to do a group reply, i.e. keep the Cc: to -mentors.
> Nothing private here :)
oops, didn't realise it. sorry debian-mentors 8)
> On Tue, Aug 27, 2002 at 10:02:59AM -0400, Joe Phillips wrote:
> > > > W: libopensc0: package-relation-with-self depends: libopensc0 (>=
> > > > 0.7.0-1isg)
> > > > E: libopensc0: shlib-missing-in-control-file libscam.so
> > > > usr/lib/libscam.so
>
> The above error says "(>= 0.7.0-1isg)", so you must be picking that
> dependency up from someplace else. Try removing any older versions of the
> package, and running DH_VERBOSE=1 dh_shlibdeps.
oh, I caught that one yesterday. At one point I had versioned my
package with an 'isg' tag in the revision. There were some droppings
still hanging around.
I double-checked that both shlibs files no longer have this dependancy
and that all versions of the package were removed from my system yet I
still get the first warning.
> > > > libscam.so isn't built with a SONAME or version, the other libraries
> > > > are.
> > >
> > > libscan.so is either not a shared library, or a broken shared library, then.
> > >
> > > If the former, move it out of /usr/lib and into a private directory like
> > > /usr/lib/something. If the latter, fix it by specifying the SONAME.
> >
> > I'll follow-up with the upstream on this. It seems to be a shared
> > library. eg. 'file' reports shared library, ldd will read it and report
> > its dependancies, some of the other binaries depend on it, etc.
> >
> > As for a broken shared library, that may hold some water. 'strip'
> > doesn't like the file, there are other errors regarding the file when I
> > build the package - though the make doesn't report any problems.
>
> (make that strip --strip-unneeded, not merely strip)
>
> > Any suggestions on other tests I could run on it in order to figure out
> > what's wrong?
>
> Find the linker line in the build system... for an exercise :) run objdump
> -p on the file and see if it differs a lot from the others.
Ok, there is a warning when linking this file. here it is:
*** Warning: Linking the shared library libscam.la against the
*** static library ../../src/scrandom/libscrandom.a is not portable!
I'm not sure how to fix this but I will report it to upstream and
continue to research on the web. Are you familiar with this problem?
The output from objdump -p looks pretty similar to that of the other
libs. Nothing obviously out of place.
> > Would adding a SONAME during build resolve some of these issues? In
> > other words, does not having a SONAME cause the library breakage or
> > could there be some other reason?
>
> It doesn't cause immediate breakage, but it annihilates binary
> compatibility. That is, once the contents of libscam.so changes one day, the
> applications that used to link to it can crap out with linker errors, and
> there is no way to prevent them from doing so, other than including the
> versioned SONAME.
Based on what I read, I figured this would be the result of no SONAME.
I'm starting to think libscam.so is some sort of plugin where I suppose
the interface would remain stable over time. I've asked for
clarification from upstream.
thanks for your pointers.
-joe
--
Innovation Software Group, LLC - http://www.innovationsw.com/
Computer Automation Specialists
UNIX, Linux and Java Training
Reply to: