You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With #662 merged, it became crucial for ort-genai to have certain level of backward/forward compatibility with different version of ORT. However, the current status isn't ideal.
During my work on #724, the following observations was found on Win32.
Forward compatibility
Compile ort-genai with ORT 1.18 headers + DLLs, the wheel produced will refuse to load ORT 1.19 (ort-nightly atm):
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\jialli\AppData\Local\Anaconda3\envs\ort-genai-py311\Lib\site-packages\onnxruntime_genai\__init__.py", line 23, in <module>
raise e
File "C:\Users\jialli\AppData\Local\Anaconda3\envs\ort-genai-py311\Lib\site-packages\onnxruntime_genai\__init__.py", line 13, in <module>
from onnxruntime_genai.onnxruntime_genai import *
ImportError: DLL load failed while importing onnxruntime_genai: A dynamic link library (DLL) initialization routine failed.
The search path is correct. It's a pure DLL initialization thing. I suppose direct linkage with ORT 1.18 causes the initialization routine to expect a fixed memory layout. Using a newer version breaks this expectation.
Manually switching ORT lib to 1.18 fixes the DLL initialization issue.
Backward compatibility
Compile ort-genai with ORT 1.19 headers + DLLs, similar issue exists if you try to load ORT 1.18 :
>>> import onnxruntime_genai as oga
The requested API version [19] is not available, only API versions [1, 18] are supported in this build. Current ORT Version is: 1.18.0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\jialli\AppData\Local\Anaconda3\envs\ort-genai-py311\Lib\site-packages\onnxruntime_genai\__init__.py", line 22, in <module>
raise e
File "C:\Users\jialli\AppData\Local\Anaconda3\envs\ort-genai-py311\Lib\site-packages\onnxruntime_genai\__init__.py", line 12, in <module>
from onnxruntime_genai.onnxruntime_genai import *
ImportError: DLL load failed while importing onnxruntime_genai: A dynamic link library (DLL) initialization routine failed.
Solution
Implementing #693 on Windows should help. With #724, I see no similar issue on Linux between 1.18 and 1.19. It's still not perfect, but it hugely reduces the possibility of forementioned crashes.
This is just part of the "C++ ABI compatibility" rabbit hole. Win32 actually solves this issue decades ago. The (almost) perfect solution was named COM. Although COM is still widely used by Windows itself, it should not be considered a viable solution in the modern C++ world.
The text was updated successfully, but these errors were encountered:
Observation
With #662 merged, it became crucial for ort-genai to have certain level of backward/forward compatibility with different version of ORT. However, the current status isn't ideal.
During my work on #724, the following observations was found on Win32.
Forward compatibility
Compile ort-genai with ORT 1.18 headers + DLLs, the wheel produced will refuse to load ORT 1.19 (ort-nightly atm):
The search path is correct. It's a pure DLL initialization thing. I suppose direct linkage with ORT 1.18 causes the initialization routine to expect a fixed memory layout. Using a newer version breaks this expectation.
Manually switching ORT lib to 1.18 fixes the DLL initialization issue.
Backward compatibility
Compile ort-genai with ORT 1.19 headers + DLLs, similar issue exists if you try to load ORT 1.18 :
Solution
Implementing #693 on Windows should help. With #724, I see no similar issue on Linux between 1.18 and 1.19. It's still not perfect, but it hugely reduces the possibility of forementioned crashes.
This is just part of the "C++ ABI compatibility" rabbit hole. Win32 actually solves this issue decades ago. The (almost) perfect solution was named COM. Although COM is still widely used by Windows itself, it should not be considered a viable solution in the modern C++ world.
The text was updated successfully, but these errors were encountered: