Building a Dynamic Module
Dynamic modules are system-dependent. This section explains how to compile and install a dynamic module properly, or in other words how to create a shared library that will load correctly, depending on the system you are using.
UNIX Systems
If you are working on UNIX, use the following generic syntax:
<CCC> -c -O -I$ILVHOME/include moduleSrc.cpp
<MAKESHLIB> -o module.<SHEXT> moduleSrc.o [other object files...]
The table below lists the various options available for the different ports of Views. Note that you always have to specify the extension of the module file name.
Port Name | CCC | MAKESHLIB | SHEXT |
|---|---|---|---|
hp32_11_3.73 | aCC +DAportable -mt - AA -z +Z | aCC -b -n -mt -AA -Wl,+s | sl |
hp64_11_3.73 | aCC +DAportable -mt - AA -z +DA2.0W | aCC -b -n -mt -AA +DA2.0W | sl |
ia64-32_hpux11_6.17 | aCC -mt -z | aCC -b -n -mt -Wl,+nodefaultrpath | sl |
ia64_hpux11_6.17 | aCC +DD64 -mt -z | aCC -b -n +DD64 -mt -Wl,+nodefaultrpath | sl |
x86_sles10.0_4.1 x86_rhel5.0_4.1 | g++ -fPIC -m32 | g++ -shared -m32 | so |
x64_sles10.0_4.1 x64_rhel5.0_4.1 | g++ -fPIC -m64 | g++ -shared -m64 | so |
power32_aix5.3_7.0 power32_aix6.1_10.1 | xlC -qmkshrobj -qrtti=all | xlC -qmkshrobj=1024 | so |
power64_aix5.3_7.0 power64_aix6.1_10.1 | xlC -qmkshrobj -qrtti=all -q64 | xlC -qmkshrobj=1024 -q64 | so |
x86_solaris10_11 ultrasparc32_10_11 | CC -KPIC | CC -G -h | so |
ultrasparc64_10_11 | CC -KPIC -mt -xtarget=ultra -xarch=v9 | CC -G -h -xtarget=ultra -xarch=v9 | so |
x64_solaris10_11 | CC -KPIC -mt -xarch=amd64 | CC -G -h -xarch=amd64 | so |
If you are a:
Linux or Solaris user Make sure that the LD_LIBRARY_PATH variable contains a path to the modules to be loaded. On Linux, the executable must be linked with the library libdl.so.Sgi user You might have to add the flags "-n32 -mips" both to CCC and MAKESHLIB to link with the Views libraries.Windows Systems
On Microsoft Windows, a dynamic module is in fact a DLL.
This functionality is only available in the format dll_mda. This is due to the fact that Views stores the registered classes in a global variable that would be re-created locally by every module if we tried to link the “client” (that is, the application that loads the module) statically.
All you need to do to build your module is add the flag /DILVDLL when compiling your object files. For an optimized code, the complete set of compiler flags for the module files should be the following:.
Port Name | Compiler Flags |
|---|---|
x86_.net20* | CL /Gs /O1 /c /DWIN32 /MD /W3 /DILVDLL /I<ILVHOME>/include moduleSrc.cpp |
x64_.net20* | CL /Gs /O1 /c /DWIN64 /MD /W3 /DILVDLL /I<ILVHOME>/include moduleSrc.cpp |
Use the following lines to link your module:
LINK /SUBSYSTEM:WINDOWS /DLL <ILVHOME>/lib/[PLATFORM]/dll_mda/<lib>.lib\
<systemLibs> -OUT:<moduleName>.dll moduleSrc.obj [objectfiles...]
Note that for x64 platforms, you must also add the following linker option:
/MACHINE:X64
As mentioned, the application that you want to be module-enabled must be linked with the Views DLLs as well. Of course, as always when using DLLs, you have to make sure that your system path contains the access path to the directory where you want to store your modules.
Versioning Note
Views dynamic modules have no versioning mechanism. You must make sure that the installed dynamic modules are binary-compatible with the application that loads them. This means that a module that was built with Views version X.Y will run with all the X.Y.Z versions, but will have to be recompiled if loaded by an application that was developed with Views X.W.
Published date: 05/24/2022
Last modified date: 02/24/2022
