www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DUB linking to local library

reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
I have been writing bindings for the GDAL library (www.gdal.org). 
   I recently updated my bindings to the latest release of GDAL 
(2.0).

Before adding my bindings to code.dlang.org I want to run some 
tests.  I've built GDAL2 locally and want to link my bindings to 
this library.  However, I also have the older GDAL libraries 
(1.11) installed system wide on my machine.

My GDAL bindings have the following dub.json file:

{
	"name": "gdald",
	"description": "D bindings for the Geospatial Data Abstraction 
Library (GDAL).",
	"homepage": "https://github.com/craig-dillabaugh/TBD",
	"homepage": "http://www.gdal.org/",
	"importPaths":["."],
	"targetType":"sourceLibrary",
	"license": "MIT",
	"authors": [
		"Craig Dillabaugh"
	],
	"libs" : ["gdal"]
}

While my test program appears as follows:

{
	"name": "gdaltest",
	"description": "Test cases for GDAL D.",
	"copyright": "Copyright © 2014, Craig Dilladub bubaugh.",
	"authors": [
		"Craig R. Dillabaugh"
	],
	"dependencies": {
		"gdald" : {"version": "~master"}
	},
	"lflags" : [ 
"-L/home/craig2/code/gdal-2.0.0/lib64/libgdal.so.20.0.0" ],
	"libs" : ["gdal"],
	"targetPath" : ".",
	"targetType" : "executable"
}

I used add-local so that my test program could see my bindings.

My issue is that while everything compiles OK (with dub build) 
the resulting executable gdaltest seems to be linked with the 
system gdal.so file and not the libgdal.so.20.0.0 file I 
specified with lflags.

ldd prints out:

ldd gdaltest
         linux-vdso.so.1 (0x00007ffe417e2000)
         libgdal.so.1 => /usr/lib64/libgdal.so.1 
(0x00007faabacf8000)

So how can I force my application to link to my local copy of 
GDAL2 at /home/craig2/code/gdal-2.0.0/lib64.  Any help is 
appreciated.


Craig
Aug 03 2015
parent reply "Joakim =?UTF-8?B?QnLDpG5uc3Ryw7ZtIg==?= <notfornow dev.null.com> writes:
On Tuesday, 4 August 2015 at 02:26:17 UTC, Craig Dillabaugh wrote:

 So how can I force my application to link to my local copy of 
 GDAL2 at /home/craig2/code/gdal-2.0.0/lib64.  Any help is 
 appreciated.


Hi,

I recently ran into similare problems, different lib.
Try changing:
"lflags" : 
["-L/home/craig2/code/gdal-2.0.0/lib64/libgdal.so.20.0.0" ]
"libs" : ["gdal"]
to:
"lflags" : ["-L/home/craig2/code/gdal-2.0.0/lib64/" ]
"libs" : [":libgdal.so.20.0.0"]

observe the flags dub passes on to dmd by using --vverbose

//Joakim
Aug 03 2015
parent reply "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 4 August 2015 at 02:45:21 UTC, Joakim Brännström 
wrote:

 On Tuesday, 4 August 2015 at 02:26:17 UTC, Craig Dillabaugh 
 wrote:

 So how can I force my application to link to my local copy of 
 GDAL2 at /home/craig2/code/gdal-2.0.0/lib64.  Any help is 
 appreciated.


 Hi,

 I recently ran into similare problems, different lib.
 Try changing:
 "lflags" : 
 ["-L/home/craig2/code/gdal-2.0.0/lib64/libgdal.so.20.0.0" ]
 "libs" : ["gdal"]
 to:
 "lflags" : ["-L/home/craig2/code/gdal-2.0.0/lib64/" ]
 "libs" : [":libgdal.so.20.0.0"]

 observe the flags dub passes on to dmd by using --vverbose

 //Joakim


Thanks.  Everything compile perfectly, and now the correct libs 
are linked it seems, but I still have an issue with the 
executable:

ldd gdaltest
         linux-vdso.so.1 (0x00007ffe63381000)
         libgdal.so.20 => not found

I can now run it with:

LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64 ./gdaltest

But it appears the LD_LIBRARY_PATH hack is causing havoc with 
other libraries, as I get errors loading other shared libraries 
when I do that.
Aug 03 2015
next sibling parent reply "Joakim =?UTF-8?B?QnLDpG5uc3Ryw7ZtIg==?= <notfornow dev.null.com> writes:
On Tuesday, 4 August 2015 at 03:20:38 UTC, Craig Dillabaugh wrote:

 ldd gdaltest
         linux-vdso.so.1 (0x00007ffe63381000)
         libgdal.so.20 => not found

 I can now run it with:

 LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64 ./gdaltest

 But it appears the LD_LIBRARY_PATH hack is causing havoc with 
 other libraries, as I get errors loading other shared libraries 
 when I do that.


Linkers, so fun they are...
https://wiki.debian.org/RpathIssue

As you can see in the search order RPATH takes precedence over 
LD_LIBRARY_PATH.
If we assume that you want LD_LIBRARY_PATH to be able to override 
the lib you could use the following flags.

"lflags" : [ "--enable-new-dtags", 
-"rpath=/home/craig2/code/gdal-2.0.0/lib64/", 
"-L/home/craig2/code/gdal-2.0.0/lib64/" ]

you can see what it is in the binary with: readelf --dynamic 
gdaltest|grep PATH

This should make LD_LIBRARY_PATH redundant.

//Joakim
Aug 03 2015
parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 4 August 2015 at 04:21:27 UTC, Joakim Brännström 
wrote:

 On Tuesday, 4 August 2015 at 03:20:38 UTC, Craig Dillabaugh 
 wrote:


clip

 Linkers, so fun they are...
 https://wiki.debian.org/RpathIssue

 As you can see in the search order RPATH takes precedence over 
 LD_LIBRARY_PATH.
 If we assume that you want LD_LIBRARY_PATH to be able to 
 override the lib you could use the following flags.

 "lflags" : [ "--enable-new-dtags", 
 -"rpath=/home/craig2/code/gdal-2.0.0/lib64/", 
 "-L/home/craig2/code/gdal-2.0.0/lib64/" ]

 you can see what it is in the binary with: readelf --dynamic 
 gdaltest|grep PATH

 This should make LD_LIBRARY_PATH redundant.

 //Joakim


I knew using LD_LIBRARY_PATH was frowned upon, thanks for 
enlightening me on the correct way to handle this.  Works 
beautifully now.
Aug 04 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 4 August 2015 at 03:20:38 UTC, Craig Dillabaugh wrote:

 I can now run it with:

 LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64 ./gdaltest

 But it appears the LD_LIBRARY_PATH hack is causing havoc with 
 other libraries, as I get errors loading other shared libraries 
 when I do that.


At the very least you want to do:

LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64:$LD_LIBRARY_PATH ./gdaltest
Aug 04 2015
parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Tuesday, 4 August 2015 at 08:18:58 UTC, John Colvin wrote:

 On Tuesday, 4 August 2015 at 03:20:38 UTC, Craig Dillabaugh 
 wrote:

 I can now run it with:

 LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64 ./gdaltest

 But it appears the LD_LIBRARY_PATH hack is causing havoc with 
 other libraries, as I get errors loading other shared 
 libraries when I do that.


 At the very least you want to do:

 LD_LIBRARY_PATH=/home/craig2/code/gdal-2.0.0/lib64:$LD_LIBRARY_PATH ./gdaltest


Thanks!
Aug 04 2015