Ari<br><br>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:<br><br> string path = Environment.GetEnvironmentVariable("PATH");<br>
if (!path.Contains(gdal_bin_path))<br> {<br> Environment.SetEnvironmentVariable("PATH", gdal_bin_path + ";" + path);<br> }<br>
Gdal.SetConfigOption("GDAL_DRIVER_PATH", gdal_driver_path);<br><br>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.<br>
<br>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.<br><br>Best regards,<br><br>Tamas <br><br><br>
<br><br><div class="gmail_quote">2011/1/6 Ari Jolma <span dir="ltr"><<a href="mailto:ari.jolma@gmail.com">ari.jolma@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 01/06/2011 03:25 PM, Tamas Szekeres wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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)?<br>
</blockquote>
<br></div>
:) 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best regards,<br><font color="#888888">
<br>
Ari</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>