Re: Dynamic libraries and GHCi

older
Re: [Haskell-cafe] cabal: problem...

John Lato

18 May 2010 18 May '10

12:48 p.m.

From: Simon Marlow

...
...
But currently there is one problem with "GhcShared=YES": with this option, the stage-2 compiler gets linked dynamically but the corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around this by manually symlinking all the dynamic libraries to ./inplace/lib and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have -rpath). This is another issue we need to resolve before we can switch to a dynamically-linked GHCi.

Basically there's a fair bit to do to make a dynamic GHCi a reality, and before we can do anything there are some tricky decisions to make.

When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1. John

Show replies by date

Simon Marlow

20 May 20 May

6:23 a.m.

New subject: Dynamic libraries and GHCi

On 18/05/2010 17:48, John Lato wrote:

...

...
From: Simon Marlow

...
...
But currently there is one problem with "GhcShared=YES": with this option, the stage-2 compiler gets linked dynamically but the corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around this by manually symlinking all the dynamic libraries to ./inplace/lib and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have -rpath). This is another issue we need to resolve before we can switch to a dynamically-linked GHCi.

Basically there's a fair bit to do to make a dynamic GHCi a reality, and before we can do anything there are some tricky decisions to make.

When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1.

It was my understanding that OS X doesn't have -rpath from reading http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management and from what I remember Mac people saying in the past. Or maybe they were just saying that -rpath is not the right thing on OS X because libraries themselves have paths baked in. Cheers, Simon

Brandon S. Allbery KF8NH

8:07 a.m.

New subject: Dynamic libraries and GHCi

On May 20, 2010, at 06:23 , Simon Marlow wrote:

...

On 18/05/2010 17:48, John Lato wrote:

...
...
From: Simon Marlow

...
But currently there is one problem with "GhcShared=YES": with this option, the stage-2 compiler gets linked dynamically but the corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around this by manually symlinking all the dynamic libraries to ./ inplace/lib and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have -rpath). This is another issue we need to resolve before we can switch to a dynamically-linked GHCi.

When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1.

It was my understanding that OS X doesn't have -rpath from reading

http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management

and from what I remember Mac people saying in the past. Or maybe they were just saying that -rpath is not the right thing on OS X because libraries themselves have paths baked in.

The latter. Also, I'd recommend DYLD_FALLBACK_LIBRARY_PATH per Apple recommendations, as you can otherwise get weird results. Note also that the baked-in path is the path of last resort. It might be possible to (ab)use this. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

John Lato

8:29 a.m.

New subject: Dynamic libraries and GHCi

On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH wrote:

...

On May 20, 2010, at 06:23 , Simon Marlow wrote:

...
On 18/05/2010 17:48, John Lato wrote:

...
...
From: Simon Marlow

...
But currently there is one problem with "GhcShared=YES": with this option, the stage-2 compiler gets linked dynamically but the corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around this by manually symlinking all the dynamic libraries to ./inplace/lib and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have -rpath). This is another issue we need to resolve before we can switch to a dynamically-linked GHCi.

When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1.

It was my understanding that OS X doesn't have -rpath from reading

http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management

and from what I remember Mac people saying in the past. Or maybe they were just saying that -rpath is not the right thing on OS X because libraries themselves have paths baked in.

The latter. Also, I'd recommend DYLD_FALLBACK_LIBRARY_PATH per Apple recommendations, as you can otherwise get weird results.

Apparently -rpath was only added in 10.5, so the former was previously true also. According to the ld manpage, -rpath only has an effect when the library's load path begins with @rpath/, which seems to break the usual OS X loading scheme so you then have to use -rpath. According to the dyld docs, it looks like -rpath is meant to be used as a last resort when other mechanisms aren't feasible. In particular, "The use of @rpath is most useful when you have a complex directory structure of programs and dylibs which can be installed anywhere, but keep their relative positions." [1] I suppose I'd agree that it's best avoided on OSX if it can be helped. John [1] http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPag...

Brandon S. Allbery KF8NH

8:42 a.m.

New subject: Dynamic libraries and GHCi

On May 20, 2010, at 08:29 , John Lato wrote:

...

On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH wrote:

...
On May 20, 2010, at 06:23 , Simon Marlow wrote:

...
On 18/05/2010 17:48, John Lato wrote:

...
...
From: Simon Marlow

...
But currently there is one problem with "GhcShared=YES": with this option, the stage-2 compiler gets linked dynamically but the corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around this by manually symlinking all the dynamic libraries to ./ inplace/lib and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have -rpath). This is another issue we need to resolve before we can switch to a dynamically-linked GHCi.

When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1.

It was my understanding that OS X doesn't have -rpath from reading

http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management

and from what I remember Mac people saying in the past. Or maybe they were just saying that -rpath is not the right thing on OS X because libraries themselves have paths baked in.

The latter. Also, I'd recommend DYLD_FALLBACK_LIBRARY_PATH per Apple recommendations, as you can otherwise get weird results.

According to the dyld docs, it looks like -rpath is meant to be used as a last resort when other mechanisms aren't feasible. In particular, "The use of @rpath is most useful when you have a complex directory structure of programs and dylibs which can be installed anywhere, but keep their relative positions." [1]

I suppose I'd agree that it's best avoided on OSX if it can be helped.

Interesting, considering that Apple's recommended use case appears to be exactly what we're looking for. Oh, also? @rpath isn't mentioned in dyld(1) on Leopard and is barely referenced in ld(1), which is why I missed it (and probably part of why -rpath was ignored). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

John Lato

11:24 a.m.

New subject: Dynamic libraries and GHCi

On Thu, May 20, 2010 at 1:42 PM, Brandon S. Allbery KF8NH wrote:

...

On May 20, 2010, at 08:29 , John Lato wrote:

...
On Thu, May 20, 2010 at 1:07 PM, Brandon S. Allbery KF8NH wrote:

...
On May 20, 2010, at 06:23 , Simon Marlow wrote:

...
On 18/05/2010 17:48, John Lato wrote:

...
...
From: Simon Marlow > > But currently there is one problem with "GhcShared=YES": with this > option, the stage-2 compiler gets linked dynamically but the > corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH, > thus ./inplace/bin/ghc-stage2 doesn't run at all. I could work around > this by manually symlinking all the dynamic libraries to > ./inplace/lib > and setting (DY)LD_LIBRARY_PATH to there, but obvisouly there should > be a solution better than this.

On Linux we link the binary using -rpath (I know OS X doesn't have -rpath). This is another issue we need to resolve before we can switch to a dynamically-linked GHCi.

When you say OSX doesn't have -rpath, do you mean there's some problem with using -rpath on OSX? I have code that links to a 3rd-party library (libcudart.dylib) at runtime and it seems to use -rpath fine. This is with ghc-6.12.1.

It was my understanding that OS X doesn't have -rpath from reading

http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/Management

and from what I remember Mac people saying in the past. Or maybe they were just saying that -rpath is not the right thing on OS X because libraries themselves have paths baked in.

The latter. Also, I'd recommend DYLD_FALLBACK_LIBRARY_PATH per Apple recommendations, as you can otherwise get weird results.

According to the dyld docs, it looks like -rpath is meant to be used as a last resort when other mechanisms aren't feasible. In particular, "The use of @rpath is most useful when you have a complex directory structure of programs and dylibs which can be installed anywhere, but keep their relative positions." [1]

I suppose I'd agree that it's best avoided on OSX if it can be helped.

Interesting, considering that Apple's recommended use case appears to be exactly what we're looking for.

In that case, maybe -rpath is the right thing to do? I don't know much about Apple's dev. guidelines, so I won't make any recommendations.

...

Oh, also? @rpath isn't mentioned in dyld(1) on Leopard and is barely referenced in ld(1), which is why I missed it (and probably part of why -rpath was ignored).

At my most charitable, I'd describe Apple's docs for command-line tools incomplete at best. John

5479

Age (days ago)

5481

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Brandon S. Allbery KF8NH
John Lato
Simon Marlow