Neil Williams wrote: > On Mon, 15 Oct 2007 13:40:43 -0300 > Felipe Sateler <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
