On Tue, Feb 01, 2005 at 02:31:27AM +0100, Miriam Ruiz wrote: > Hi, Hiya,
> Now running lintian... > E: maserver: > sharedobject-in-library-directory-not-actually-a-shlib > usr/lib/libmaserver.so.1.0 > Finished running lintian. Try lintian -i: you'll see this type of thing: A shared object was identified in a library directory (i.e. a directory in the standard linker path) which doesn't have a SONAME. This is usually an error. (From http://lintian.debian.org/reports/Tsharedobject-in-library-directory-not-actually-a-shlib.html) So, you need to edit the build system (or ask upstream) to make gcc have an option like "-Wl,-soname,libmaserver.so.1". > I 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). Or rpath, which you don't want or need (rpath is used when generating a binary, and it adds a directory in which to look for depended-on shared librarys). > I don't think linking statically the dynamic library is an > opcion, because i feel that the plugins use it as well as > the program, and I'd finally have it in every binary. Right. > Any suggestions? Thanks in advance for your help. You should also edit the line with "dh_shlibdeps". You'll notice that if you unintall the package and then build it, this line will generate a warning. That's debhelper trying to figure out "what package provides this shared library". Oftentimes, its a different package. The -l option to dh_shlibdeps tells it where to look for the libraries when a given package includes shared libraries as well as libraries that depend on them. > Link to dynamic library: usr/lib/maserver.so -> > usr/lib/maserver.so.1.0 Also, do you actually need that link? Hmm. Its not a bad idea, I guess, but will any other packages Build-Depend on maserver? More typically, binaries are in one package, and libraries in another package (on which the binary package depends), and then a development package (libfoo-dev) includes shared libraries (sometimes) as well as the libfoo.so => libfoo.so.0 symlink (which is only needed such that the linker can go from -lfoo to libfoo.so). Cheers, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
