|
"Are you using make_dll to create your DLL's and DLM's? If not, what method are you using?"
I am on a Linux system so I am not making DLLs, but .'so' shared libraries. I'm writing DLM shared lib code in C++ and simply exporting the 'IDL_Load' function using C linkage rules (by wrapping it in an extern "C" block). I can then link this lib against libidl.so, write the '.dlm' text file, add my DLM directory to the IDL_DLM_PATH environment variable, and voila, it works perfectly.
"What compiler are you using for your DLLs?"
GCC (g++).
"What is it that you want to use the DLL and DLM for? Are you using this for a VM distribution or would you have users manually install the DLM and DLL on their machines?"
So I'm deploying my software as a binary package. I guess that means users will install it on their machines, but I'm using RPM, so I wouldn't call that 'manual'. But, yes users will have to invoke the package management system (YUM) to install my software. The DLMs are a part of my software interfaces, they allow users to supplement IDL analysis tasks with my custom C++ functionality. The user is expected to have some version of IDL already installed on their box
"Generally speaking it is not too surprising that you are having issues with using DLLs and DLMs for multiple versions of IDL. This is because the libidl.so file could potentially have some changes made which are version specific (specifically entry points into libidl.so) and they require that version of libidl.so to run properly."
Well, I might expect this for changes in major version, say IDL 7 vs. IDL 8. But, honestly, to have this restriction on the minor versions as well (8.3 vs, 8.4, for example) is rather prohibiting and forces me to question the fitness of IDL as a data analysis solution for our projects.
EDIT: I should add that I am *currently* targeting Linux systems, but the plan is to eventually support Windows and OSX as well.
|