The XSPICE subsection of the NGspice manual says this (28.6.1.1 C Function Name):
To reduce the chance of name conflicts, it is recommended that user-written code model names use the prefix ucm_ for this entry.
I tried following that advice, which resulted in this error in simulation:
Error opening code model "/usr/local/lib/ngspice/digital.cm": /usr/local/lib/ngspice/digital.cm: undefined symbol: cm_d_demo_info
Error: Library /usr/local/lib/ngspice/digital.cm couldn't be loaded!
The problem will occur if the C function name is changed after the code model
has been built. The reason is that cmpp uses the function name to construct
the name of the SPICEdev structure, but the list of such structures in the shared library (cminfo.h) is not updated.
This change to ngspice-32/src/xspice/icm/GNUmakefile.in seems to fix it.
%/cmextrn.h %/cminfo.h %/udnextrn.h %/udninfo.h %/objects.inc : $(srcdir)/%/modpath.lst $(srcdir)/%/udnpath.lst --- %/cmextrn.h %/cminfo.h %/udnextrn.h %/udninfo.h %/objects.inc : $(srcdir)/%/modpath.lst $(srcdir)/%/udnpath.lst $(srcdir)/%/*/ifspec.ifs
(Buggy formatting above introduced by Sourceforge, with no obvious way to fix.)
There is also a minor error in that part of the manual, where it says:
Note that when you subsequently write the model function in the Model Definition File, this name must agree with that of the function (i.e.,ucm_xfer), or an error will result in the linking step.
At least on Linux, the error occurs when attempting simulation, as above. I suspect the same is true on all Unix-like OSs, where shared libraries may depend on symbols defined by other binaries. MS Windows may be different, as it seems to have weaker dynamic loading support.
Diff: