Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

[Tamas Szekeres]

Ari

The only wokaround which is satisfactory to me is to set the required
enviroment at run time before the gdal bindings are used. In csharp we can
do something like:

                    string path =
Environment.GetEnvironmentVariable("PATH");
                    if (!path.Contains(gdal_bin_path))
                    {
                        Environment.SetEnvironmentVariable("PATH",
gdal_bin_path + ";" + path);
                    }
                    Gdal.SetConfigOption("GDAL_DRIVER_PATH",
gdal_driver_path);

But it requires that loading the gdal dll is happening when the interface is
used actually (in Gdal.SetConfigOption with the code above). This is the
case with the .NET runtime,  but I'm not sure how do we stand with the other
bindings in this regard.

Futher problem with this solution is that this startup code should be placed
in the user's script and not sure how this could be implemented in the gdal
bindings itself.

Best regards,

Tamas




2011/1/6 Ari Jolma <ari.jolma at gmail.com>

> On 01/06/2011 03:25 PM, Tamas Szekeres wrote:
>
>>
>> Assuming we install the gdal-perl modules in a standard location (not sure
>> where it is), do we have a common mechanism in the perl runtime to find the
>> dependent dlls without having to violate system wide settings (like the PATH
>> environment variable)?
>>
>
> :) I'm not completely satisfied (I'm also not sure I really understand the
> whole f* issue) with how Perl searches for dll's - especially dll import
> libs - in Windows.
>
> But that's configure/compile time issue. In compile time a Perl GDAL dll
> (for the bindings) is created and put into some location, which is known to
> Perl and Perl knows how to find it in runtime.
>
> Assuming I've built the binaries, then in runtime (when the GDAL module is
> called for) I think somebody (because the Perl GDAL module dll has a link to
> GDAL dll that was put there in compile time) asks for the GDAL dll's and
> they simply need to be available. Thus, if there is GDAL in the system (for
> example in c:\Program Files\Share\GDAL\bin) then that path needs to be in
> the PATH - I don't think there is a way around that. The PATH may be a
> temporary PATH set by somebody for Perl programs, but I think the policy
> should be that when you run GDAL.msi, the system default PATH is modified to
> have the path to the GDAL binaries.
>
> Best regards,
>
> Ari
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110106/07282900/attachment.html