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

[Rakefet]

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. 

[JonathanNeal]

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

[JonathanNeal]

@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

[Rakefet]

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...

 

[JonathanNeal]

@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.

[Rakefet]

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.  

[Rakefet]

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.