Ticket #456 (closed task: fixed)
DllLoader should handle missing files better
|Reported by:||Philip||Owned by:||evans|
|Priority:||Nice to Have||Milestone:|
|Component:||Core engine||Keywords:||simple review|
DllLoader is used to load the Atlas and Collada libraries at run-time. In a Debug build, it tries to load AtlasUI_dbg.dll (./libAtlasUI_dbg.so on Linux). In a Release build, it loads AtlasUI.dll (./libAtlasUI.so).
(Ignore the comment in DllLoader saying "it is critical that compiler options are the same between app and SO" - that is untrue, since the libraries are designed to be safely mixed with different compiler options. We just want to use the Debug library with Debug builds in order to help debugging and error-detection.)
Because Atlas is a bit awkward and slow to compile, it's disabled by default on Windows, so AtlasUI_dbg.dll won't be created. But AtlasUI.dll will exist, because we put a pre-compiled binary in SVN (for non-programmers to use). Rather than fail to load Atlas in Debug builds because there's no matching library, it should fall back on AtlasUI.dll and load that one instead.
So in Debug builds on Windows, DllLoader needs to look for the Debug library then the Release library; in all other cases it should just look for the single appropriate library.
In all cases, it shouldn't trigger internal error messages in dlopen: it should check that the file exists before trying to open it, and give a nice friendly error message if it can't find anything. (Or maybe it should try to open it first, and change the Windows emulation of dlopen in wdlfcn.cpp to silently return a failure code that the caller can check.)
- Status changed from assigned to closed
- Resolution set to fixed