On Tue, Feb 01, 2005 at 02:31:27AM +0100, Miriam Ruiz wrote: > I'm trying to package a program named maserver ( > http://www.babichev.info/en/projects/maserver/index.html > ), which is an audio streaming server for LAN and > internet. > The file structure resulting from install (with some > tweaks) is right now: > Configuration files: > etc/maserver/* > Binary: > usr/bin/maserver > Plugins: > usr/lib/maserver/* > Dynamic library: > usr/lib/maserver.so.1.0 > Link to dynamic library: > usr/lib/maserver.so -> usr/lib/maserver.so.1.0 > As well as usr/share/doc/*, usr/share/man/* and so. > When I do debuild, and lintian is run, i get the > following message: > Now running lintian... > E: maserver: > sharedobject-in-library-directory-not-actually-a-shlib > usr/lib/libmaserver.so.1.0 > Finished running lintian. > I've been asking in IRC a bit, and they told me that > there shouldn't be a shared library in a program. It's true that you usually should not have shared libraries in an application package, but that is not the meaning of this error. This error means that the file that you have placed in /usr/lib is *not a shared library*. If the file does not declare an SONAME, it's not a shared library and should not be placed in /usr/lib. But for that matter, if /usr/bin/maserver is the only thing that will ever use this library, it shouldn't be a shared library or plugin at all: it should be statically linked into your binary. > can move to /usr/lib/maserver/* and that solves > lintian error, but the program wouldn't locate it in > runtime execution (unless i added a starting script > exporting where to look for dynamic libraries). If the plugins are only ever used from /usr/bin/maserver, it's not really necessary that they link to a library, since those plugins will have access to symbols from the application itself. Using a separate library *does* give you the advantage of being able to build the plugins using "-Wl,-z,defs", but if you're not building that way it doesn't matter. If you are going to keep the shared code in a separate .so, it must stay in /usr/lib, and you must set an SONAME for it. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature