• Peter Alexander (14/14) Sep 18 2014 I downloaded this:
• Jacob Carlborg (10/24) Sep 18 2014 Hmm, looks like it searches for libconfig++ relative to the executable
• David Nadlinger via digitalmars-d-ldc (8/9) Sep 19 2014 Yes. If somebody could investigate how to integrate building a static
• Jacob Carlborg (6/9) Sep 19 2014 There's a static version of libconfig available from Macports. Just a

"Peter Alexander" <peter.alexander.au gmail.com> writes:

I downloaded this:

https://github.com/ldc-developers/ldc/releases/download/v0.14.0/ldc2-0.14.0-osx-x86_64.tar.gz

Extracted it, then created a symlink from ~/bin/ldc2 to the 
extracted binary.

Then, if I run ldc2 from this symlink, I get this:

dyld: Library not loaded:  executable_path/libconfig++.9.dylib
   Referenced from: /Users/pja/bin/ldc2
   Reason: image not found
Trace/BPT trap: 5

I've "fixed" it by not creating the symlink and instead just 
adding the ldc2 bin path to my $PATH, but I was wondering if 
there is anything ldc2 can do to avoid this (can libconfig++ be 
statically linked)? Just worried that other people might run into 
the same, scary-looking error and abandon ldc2. Would be a shame.

Jacob Carlborg <doob me.com> writes:

On 18/09/14 22:55, Peter Alexander wrote:
 I downloaded this:

 https://github.com/ldc-developers/ldc/releases/download/v0.14.0/ldc2-0.14.0-osx-x86_64.tar.gz


 Extracted it, then created a symlink from ~/bin/ldc2 to the extracted
 binary.

 Then, if I run ldc2 from this symlink, I get this:

 dyld: Library not loaded:  executable_path/libconfig++.9.dylib
    Referenced from: /Users/pja/bin/ldc2
    Reason: image not found
 Trace/BPT trap: 5

 I've "fixed" it by not creating the symlink and instead just adding the
 ldc2 bin path to my $PATH, but I was wondering if there is anything ldc2
 can do to avoid this (can libconfig++ be statically linked)? Just
 worried that other people might run into the same, scary-looking error
 and abandon ldc2. Would be a shame.

Hmm, looks like it searches for libconfig++ relative to the executable 
path. If I recall correctly that load path can be changed using the 
command line tool "install_name_tool". To be able to use that properly 
LDC can help by building with the "-headerpad_max_install_names" flag.

Alternatively I guess you can just symlink the libconfig++ as well to 
the same location as the symlink for the executable.

Of course, static linking would be easiest.

-- 
/Jacob Carlborg

David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:

On 19 Sep 2014, at 8:08, Jacob Carlborg via digitalmars-d-ldc wrote:
 Of course, static linking would be easiest.

Yes. If somebody could investigate how to integrate building a static 
version of libconfig++ into our packaging scripts [1], that would be 
awesome.

Cheers,
David


[1] 
https://github.com/ldc-developers/ldc-scripts/tree/master/ldc2-packaging

Jacob Carlborg <doob me.com> writes:

On 19/09/14 10:18, David Nadlinger via digitalmars-d-ldc wrote:

 Yes. If somebody could investigate how to integrate building a static
 version of libconfig++ into our packaging scripts [1], that would be
 awesome.

There's a static version of libconfig available from Macports. Just a 
matter to add a linker flag indicating it should link with the static 
library.

-- 
/Jacob Carlborg