On Fri, 2010-01-15 at 21:48 +, Thomas Schilling wrote:
> 2010/1/13 Duncan Coutts
>
> > I'm not sure I can. Apparently I just don't get what other people think
> > is wrong with rpath.
>
> Quoting from: http://en.wikipedia.org/wiki/Rpath_(linking)
> "he primary disadvantage of using RPATH is
2010/1/13 Duncan Coutts
> I'm not sure I can. Apparently I just don't get what other people think
> is wrong with rpath.
Quoting from: http://en.wikipedia.org/wiki/Rpath_(linking)
"he primary disadvantage of using RPATH is that it overrides the
LD_LIBRARY_PATH settings which makes things like ru
On Tue, 2010-01-12 at 16:52 +, Simon Marlow wrote:
> On 12/01/10 10:52, Duncan Coutts wrote:
>
> > This would also be relevant for the ghc build process. Currently for ghc
> > we do not use rpath at all for the .so files for the core packages. I
> > did it that way initially just to get it to
On 12/01/10 10:52, Duncan Coutts wrote:
This would also be relevant for the ghc build process. Currently for ghc
we do not use rpath at all for the .so files for the core packages. I
did it that way initially just to get it to work. Ideally we should move
to setting the rpath for the final $pref
Brief summary from the rpath discussion between Andrew and myself:
One reason people find rpath annoying is that it overrides the
LD_LIBRARY_PATH. This is the historical behaviour of the ELF DT_RPATH
entry. There is a newer ELF DT_RUNPATH entry which fixes this behaviour,
ie lets LD_LIBRARY_PATH o
On Tue, 2010-01-12 at 09:01 +, Andrew Suffield wrote:
> > This is a main linking to libfoo.so via rpath but overridden to link to
> > a separate ./bar/libfoo.so that exports a different implementation of
> > extern int foo();
>
> asuffi...@cyclone:~/tmp$ echo 'int foo = 42;' > foo42.c
> asuff
On Tue, Jan 12, 2010 at 08:22:48AM +, Duncan Coutts wrote:
> man ld.so says:
>
> The shared libraries needed by the program are searched for in the
> following order:
>
> * (ELF only) Using the directories specified in the DT_RPATH
> dynamic section attribute of the binary if
On Tue, 2010-01-12 at 01:49 +, Andrew Suffield wrote:
> On Tue, Jan 12, 2010 at 12:16:31AM +, Duncan Coutts wrote:
> > On Mon, 2010-01-11 at 20:19 +, Andrew Suffield wrote:
> >
> > > To reiterate, this is the exemplar use case for relocatable objects:
> > >
> > > Install ghc and some
On Tue, Jan 12, 2010 at 12:16:31AM +, Duncan Coutts wrote:
> On Mon, 2010-01-11 at 20:19 +, Andrew Suffield wrote:
>
> > To reiterate, this is the exemplar use case for relocatable objects:
> >
> > Install ghc and some libraries to /usr/local/
> > Build some applications with ghc and inst
On Mon, 2010-01-11 at 20:19 +, Andrew Suffield wrote:
> To reiterate, this is the exemplar use case for relocatable objects:
>
> Install ghc and some libraries to /usr/local/
> Build some applications with ghc and install them into /home/asuffield/bin/
> mv /usr/local/lib/*ghc* /srv/nfs-app-s
On Mon, Jan 11, 2010 at 04:32:02PM +, Duncan Coutts wrote:
> There are advantages to not doing so. In particular multiple instances
> of the same version of a package, or multiple instances of the same ghc
> version can co-exist happily if they're isolated.
Why is this useful? I can't imagine
On Sun, 2010-01-10 at 21:22 +, Andrew Suffield wrote:
> On Sun, Jan 10, 2010 at 07:11:43PM +, Duncan Coutts wrote:
> > Right. I think it's much more sensible to use isolated locations for
> > installed library files. It makes it much easier to have multiple
> > instances of things.
>
> Thi
On Sun, Jan 10, 2010 at 07:11:43PM +, Duncan Coutts wrote:
> Right. I think it's much more sensible to use isolated locations for
> installed library files. It makes it much easier to have multiple
> instances of things.
This does not appear to be an issue because the .so files are uniquely
na
On Sat, 2010-01-02 at 13:47 +, Simon Marlow wrote:
> We had a similar plan in the past, see e.g.
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2007-June/012740.html
>
> and for background:
>
> http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management
>
> However, Dun
On 01/01/10 00:54, Andrew Suffield wrote:
On Fri, Jan 01, 2010 at 01:38:58AM +0100, Lars Viklund wrote:
On Wed, Dec 30, 2009 at 06:29:23PM +, Andrew Suffield wrote:
I've been thinking about this. The only reason why rpath is needed is
because the .so files are being stuck in lib/ghc-$versio
On Fri, Jan 01, 2010 at 01:38:58AM +0100, Lars Viklund wrote:
> On Wed, Dec 30, 2009 at 06:29:23PM +, Andrew Suffield wrote:
> > I've been thinking about this. The only reason why rpath is needed is
> > because the .so files are being stuck in lib/ghc-$version/ instead of
> > going into lib/ di
On Wed, Dec 30, 2009 at 06:29:23PM +, Andrew Suffield wrote:
> On Wed, Dec 30, 2009 at 02:20:41PM +, Duncan Coutts wrote:
> > On Wed, 2009-12-30 at 12:09 +0100, Maxime Henrion wrote:
> >
> > > - Is there a plan to deal with the ldconfig cache on UNIX systems? As
> > > things are now, I had
On Wed, Dec 30, 2009 at 02:20:41PM +, Duncan Coutts wrote:
> On Wed, 2009-12-30 at 12:09 +0100, Maxime Henrion wrote:
>
> > - Is there a plan to deal with the ldconfig cache on UNIX systems? As
> > things are now, I had to manually add all the package directories
> > under /usr/local/lib/ghc-6
18 matches
Mail list logo
