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

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.

     Innovation Software Group, LLC - http://www.innovationsw.com/
                Computer Automation Specialists
                 UNIX, Linux and Java Training

Reply to: