On Tue, Nov 13, 2007 at 08:59:32PM +0100, Josselin Mouette wrote:
> Le mardi 13 novembre 2007 à 11:01 -0800, Steve Langasek a écrit :
> > > The current packages install the dynamic libraries simply to /usr/lib
> > > which I want to fix now. They should go to
> > > ${ARB_HOME}/lib
> > FWIW,
On Sat, Nov 17, 2007 at 04:24:18PM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> > On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> > FWIW, I don't agree that this is a fix. In one sense it makes /u
Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
> "cleaner" by moving private libs into a private dire
On Tue, 13 Nov 2007, Steve Langasek wrote:
FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
"cleaner" by moving private libs into a private directory; however:
Well, I'm perfectly willing to adopt your suggestions, but I have to admit
that the authors of this software do
Hi,
Le mardi 13 novembre 2007 à 11:01 -0800, Steve Langasek a écrit :
> > The current packages install the dynamic libraries simply to /usr/lib
> > which I want to fix now. They should go to
>
> > ${ARB_HOME}/lib
>
> FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
>
On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> At installation time the filles will be installed to a directory
> ARB_HOME=/usr/lib/arb
> were the binaries go to
> ${ARB_HOME}/bin
> The current packages install the dynamic libraries simply to /usr/lib
> which I want
On Tue, Nov 06, 2007 at 10:18:43AM +, Ben Hutchings wrote:
> You should use "-Wl,-rpath -Wl,/usr/lib/arb/lib" instead of
> "-Lrpath /usr/lib/arb/lib".
Better use the shorter form "-Wl,-rpath,/usr/lib/arb/lib".
Bastian
--
The best diplomat I know is a fully activated phaser bank.
On Tue, 2007-11-06 at 08:51 +0100, Andreas Tille wrote:
> Could anybody enlighten me what compiler options I have to give to
> enable compile time and runtime correctly working. I tried
>
> g++ ... -Lrpath /usr/lib/arb/lib ... -L/lib
>
> which just caused
>
> /usr/bin/ld: /usr/lib/a
Hi,
I would like to seek for some clarification of the thread from September
this year because I also have to use the rpath feature, but it became
not really clear to me, how this has to be used. I need it for the
package arb. At compile time the libraries are
/lib/lib*.so
the binaries t
> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program
No.
$ORIGIN is dynamic linker feature, it is expanded to the directory where
executable resides.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Wed, Sep 26, 2007 at 10:36:18AM +, Reinhard Tartler wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>
> > libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> > variable apparently defined by the openoffice startup script/program.
> > This variable is not set a bu
On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog <[EMAIL PROTECTED]>
wrote:
> Hello,
>
> _rene_ reported me a failure with openoffice and the new dpkg-shlibdeps.
>
>
> Scanning
> debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so
> (for Depends field)
> dpkg-s
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program.
> This variable is not set a build time (and the code wasn't expecting
> variables at that place anyway).
On Wed, Sep 26, 2007 at 11:56:39AM +0200, Francesco P. Lovergine wrote:
> On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog wrote:
> > On the other hand, maybe I should just be less picky for shared objects
> > without SONAME... I'm not sure about it.
> >
>
> I would suggest that, there a
On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog wrote:
> On the other hand, maybe I should just be less picky for shared objects
> without SONAME... I'm not sure about it.
>
I would suggest that, there are a few programs out there which use
many internal use shlibs without a soname and
15 matches
Mail list logo
