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

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

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.

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

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

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.

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!