Changes between Initial Version and Version 1 of Ticket #12479, comment 24


Ignore:
Timestamp:
Sep 23, 2016 10:06:41 AM (14 months ago)
Author:
darchon
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12479, comment 24

    initial v1  
    11Given that I'm the one who wrote GHC's {{{@rpath}}}-relative {{{install_name}}} code, and Cabal's {{{RPATH}}}-handling code, I want to point out one problem that needs some thought before we make all the {{{install_name}}}s {{{@rpath/libname-x.y.z/libname-x.y.z.dylib}}}: sometimes, the libraries that we link against aren't in their installed location yet.
    22
    3 And there is one particular case when this is a problem: when a Cabal {{{testsuite}}} executable is dynamically linked against the library under development. In this case, the {{{libname-x.y.z.dylib}}} is still in {{{./dist/build}}}. Now, because (currently) the {{{install_name}}} is simply {{{@rpath/libname-x.y.z.dylib}}}, we can simply execute the {{{testsuite}}} executable where the {{{DYLD_LIBRARY_PATH}}} contains {{{./dist/build}}}.
     3And there is one particular case when this is a problem: when a Cabal {{{testsuite}}} executable is dynamically linked against the library under development. In this case, the {{{libname-x.y.z.dylib}}} is still in {{{./dist/build}}}. Now, because (currently) the {{{install_name}}} is simply {{{@rpath/libname-x.y.z.dylib}}}, we can simply execute the {{{testsuite}}} executable where the {{{DYLD_LIBRARY_PATH}}} environment variable contains {{{./dist/build}}}.
    44
    5 If the {{{install_name}}} is going to be changed to {{{@rpath/libname-x.y.z/libname-x.y.z.dylib}}}[1], then we have to take care of the above-mentioned problem.
     5If the {{{install_name}}} is going to be changed to {{{@rpath/libname-x.y.z/libname-x.y.z.dylib}}}[1], then we have to take care of the above-mentioned problem. For example by changing Cabal to build the library under development in {{{./dist/build/libname-x.y.z}}}
    66
    77[1] Another solution is of course to put (or symlink) all the {{{.dylib}}}s in the {{{$lib}}} directory instead of {{{$lib/libname-x.y.z}}}, which I've seen being suggested, but is something I personally don't like it.