topic Re: Python toolbox spawns an C++ executable code with its associated GDAL DLL in Python Questions

Python toolbox spawns an C++ executable code with its associated GDAL DLL

Rakefet — Tue, 19 Oct 2021 14:55:48 GMT

Hello,

I am trying to run a third part C++ application from a python toolbox. The third party application comes as an executable file with its GDAL DLL. To run this application from the toolbox, I tried os.system(cmd_str) or subprocess.call(cmd_str, shell=False) and got the error:

I thought that the problem is incompatible versions of GDAL but when I ran os.system(cmd_str) from a Python window outside of ArcGIS pro (same environment as ArcGIS Pro) , it works. I am getting the same error when I run os.system(cmd_str) from ArcGIS Python window. I would appreciate any ideas how to solve this problem. Thanks.

Re: Python toolbox spawns an C++ executable code with its associated GDAL DLL

JonathanNeal — Tue, 19 Oct 2021 15:41:37 GMT

@Rakefet Does this blog post help you?
https://arcpy.wordpress.com/2015/08/17/arcpy-interoperability-with-c-library/

Re: Python toolbox spawns an C++ executable code with its associated GDAL DLL

JonathanNeal — Tue, 19 Oct 2021 15:53:17 GMT

@Rakefet Can you review this .py file to see if your implementation is similar?
https://github.com/arcpy/arcpy-cpp-interop/blob/master/gptool_script.py

Re: Python toolbox spawns an C++ executable code with its associated GDAL DLL

Rakefet — Tue, 19 Oct 2021 17:03:01 GMT

Thank you for your response. I am not sure gptool_script.py can help me because the third party exe is using functions from the DLL but it is not part of the DLL. To understand better the issue that I have, I invoked gdalinfo.exe (which has associated DLL). I used in my tool the command subprocess.call("<path to gdalinfo that is not part of ArcGIS path>gdalinfo <my image>") and it works. So, it is something else that causes the problem but I am clueless...

Re: Python toolbox spawns an C++ executable code with its associated GDAL DLL

JonathanNeal — Wed, 20 Oct 2021 16:39:36 GMT

@Rakefet via the virtual water cooler talk, this response seemed useful:

Normally, I would expect DLL resolution to work fine for a DLL co-located in the same directory as an executable. One approach the user might take is to try and modify the PATH environment variable prior to executing the subprocess call, this can be done for example with

from subprocess import Popen
from os import environ

my_env = environ.copy()
my_env["PATH"] = "C:/location/of/DLL;" + my_env["PATH"]
Popen(my_command, env=my_env, shell=True)

Hopefully that is sufficient. A more involved approach is using Process Monitor to see the DLL loads (and failures) as they occur.

Re: Python toolbox spawns an C++ executable code with its associated GDAL DLL

Rakefet — Thu, 21 Oct 2021 13:40:25 GMT

Thank you for the suggestion. I tried it and still getting the same error message. To be sure that the path to the DLL is passing to the process, I created python script that print the PATH environment and called it the same way and the call confirms that the first directory in the PATH is the path to the DLL.

Re: Python toolbox spawns an C++ executable code with its associated GDAL DLL

Rakefet — Thu, 21 Oct 2021 14:28:50 GMT

Hello,

I was able to run my exe file from the Python toolbox by renaming the folder of the GDAL plugin. This way it is not in the searching path. I would prefer to remove this folder from my environment but I could not find it (it is not in my environment). This is not a preferable way to work around but it works.