void mi_link_config(
    char            *l_cmd,
    char            *l_options,
    char            *c_cmd,
    char            *l_path1,
    char            *l_path2,
    char            *l_path3)

The LINK module depends on the systems compiler and linker. The location and calling convention may vary for every installation. This function overrides the built-in defaults with the custom linker command l_cmd, linker options l_options, compiler command c_cmd, and three library search paths l_path1, l_path2, and l_path3. The library search paths are simply concatenated; supporting three different arguments is a convenience for the caller because there are three defaults (user, environment, and built-in). Each of the argument paths may be a null pointer, in which case the corresponding default is not overridden.

void mi_link_set_module_handle(
    void            *mod)

This function is available and necessary only on Windows platforms. It informs all dynamically loaded shader libraries where to look for mental ray API functions. This is required when the mental ray library itself is dynamically loaded into a parent application, its functions are not automatically visible to other dynamic libraries. The mod argument should pass the return value of the GetModuleHandle function of the actual library file name, like
mi_link_set_module_handle(GetModuleHandle("oemraylib.dll")).
If this function is not called then mi_link_module defaults to GetModuleHandle.

void mi_link_register_builtin(
    const char           *fname,
    const miFunction_ptr func)

Builtin functions that are to be called via the same interface as runtime loaded modules need to be registered with the LINK module. This function allows a pointer to a function func to be entered into the symbol table under the name fname, so that it can be retrieved with mi_link_lookup. This can be used to pre-register hardcoded shaders, for example. Symbols in libraries loaded with mi_link_file_add need not to be registered in this way, as this is done when they are first looked up (or at load time if the operating system does not support dynamic symbol lookup).

miFunction_ptr mi_link_lookup(
    const char      *name)

This function looks up a function by name name in the symbol table, and returns a pointer to it. If name cannot be found, a null pointer is returned. All currently loaded libraries (loaded with mi_link_file_add) and the list of pre-registered built-ins (from mi_link_register_builtin) are searched. The external libraries are looked up before built-in functions are searched thus allowing a replacement of a built-in function with a loaded library. If multiple libraries define the same symbol, it is undefined (and operating-system dependent) which is returned.

typedef struct lmodule {
    int             refcount;               /* # of users of library */
    int             module_id;              /* module id */
    miBoolean       libgenerated;           /* generated from x.o */
    miBoolean       srcgenerated;           /* generated from inline */
    miBoolean       coremodule;             /* is a raylib coremodule */
    miBoolean       delayed;                /* entered as delayed */
    miLink_origin   origin;                 /* module type */
    char            libfile[miPATHSIZE];    /* locally loaded library */
    char            rawfile[miPATHSIZE];    /* unsubst. src/objfile */
    void            *libhandle;             /* OS handle for library */
    void            *closehandle;           /* NT auto close`n'delete */
    struct lmodule  *next;                  /* next module */
} miLinkModule;

void mi_link_info(
    miLinkModule     **lm)

Returns the head of a chain of miLinkModule records, linked with a next field. Each record describes a single linked library. If a library was linked multiple times, refcount is greater than 1; it must be unlinked with mi_link_file_remove that many times, passing the rawfile string. The libfile string is the file name after path substitution. The other fields are of little interest to the caller. The records should not be written to.

void mi_link_file_add(
    const char      *file,       /* name of a .c, .o or .so file */
    miBoolean       source,      /* .c instead of .o/.so? */
    miBoolean       verbatim,    /* came from $code .. $end code */
    miBoolean       delaylink);  /* delay linking until mi_link_delayed */

Load a source file, object file, or library. For the given file, the parameter source determines whether it is to be loaded as a source or binary file. Binary modules may be plain object files (in rare cases) or dynamically loadable modules (shared libraries, DSO or DLL). If source is miFALSE, the extension of file is checked to determine whether the file is an object file (extension .o on Unix/MacOSX or .obj on Windows) or a shared library ( .so on Unix/MacOSX or .dll on Windows). If libraries are loaded more than once, a reference count ensures that it is loaded only the first time.

The verbatim argument must be set to miTRUE if the given file is a source file that was generated from within raylib and is to be deleted on shutdown. Such source files are typically read from the scene file into a temporary file, which must be deleted when it is no longer needed.

The delaylink parameter must be set to miTRUE if this function is called very early during initialization of raylib, at a point where the number of CPUs and the networking configuration is not yet known. This is commonly the case if libraries are loaded from the command line. It is recommended to avoid this case, and to always pass miFALSE.

void mi_link_file_remove(
    const char      *file)

Remove the previously loaded source, object, or library file file. A reference count keeps track of the number of additions and removals of a module. The module is only removed from memory (and disk if appropriate) if no reference to the module is left. The identity of a module is checked only by a textual comparison of the given file name string. Do not delete a module that is still running, or mental ray will crash.

Both mi_link_file_add and mi_link_file_remove only work on the master host in a networked environment. Slave hosts ignore them.

Copyright © 1986, 2015 NVIDIA ARC GmbH. All rights reserved.