Re: package-name-doesnt-match-sonames
Neil Williams wrote:
> On Mon, 15 Oct 2007 13:40:43 -0300
> Felipe Sateler <fsateler@gmail.com> wrote:
>
>> >
>> >> The libs are specifics to this program.
>> >
>> > In which case, the libs MUST NOT be in /usr/lib/ but in /usr/lib/foo -
>> > in your case probably /usr/lib/ktranslator/. Then lintian won't bother
>> > you. You aren't building a library package, you are building an
>> > application that uses some private libraries. Don't make them public,
>> > ensure that the private libraries STAY private.
>>
>> But then one must define RPATH to allow the binary to find the library,
>> right?
>
> That isn't a problem for private libraries.
I know.
>
>> How does one ensure that the RPATH doesn't point to /usr/lib?
>
> Why would it? You set the libraries as private in the autotools and
> they get installed in a private location using rpath.
Because for some reason (broken am/ac scripts?), some autotools-based
projects define an RPATH to /usr/lib when not called explicitly
with --disable-rpath. But since I need an RPATH, I can't pass that flag to
configure.
>
>> Usually to avoid rpath one would pass --disable-rpath to configure, but
>> this can no longer be done, right?
>
> pkglib
> vs
> lib
Aha, I had never seen this. Very useful indeed. I wonder how it reacts to
the --disable-rpath flag, though (testing right now).
>
> prefixes in the Makefile.am.
>
> GnuCash is a great one for private libraries, it has dozens and dozens.
> Take a look at that source. All these use an rpath and none need to be
> concerned about /usr/lib, only /usr/lib/gnucash/foo/
I'll check it out.
>
> Then compare with libqof1 which has public libraries with SONAME
> and a package name that matches the SONAME etc.
I know how libraries with versioned SONAMEs work.
--
Felipe Sateler
Reply to: