Difference between revisions of "Package.loadlib"
From GiderosMobile
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
'''<translate>Available since</translate>:''' Gideros 2011.6<br/> | '''<translate>Available since</translate>:''' Gideros 2011.6<br/> | ||
| + | '''<translate>Class</translate>:''' [[Special:MyLanguage/package|package]]<br/> | ||
=== <translate>Description</translate> === | === <translate>Description</translate> === | ||
<translate>Dynamically links the host program with the C library libname. Inside this library, looks for a function funcname and returns this function as a C function. (So, funcname must follow the protocol (see lua_CFunction)). | <translate>Dynamically links the host program with the C library libname. Inside this library, looks for a function funcname and returns this function as a C function. (So, funcname must follow the protocol (see lua_CFunction)). | ||
Revision as of 09:27, 24 August 2018
Available since: Gideros 2011.6
Class: package
Description
Dynamically links the host program with the C library libname. Inside this library, looks for a function funcname and returns this function as a C function. (So, funcname must follow the protocol (see lua_CFunction)).
This is a low-level function. It completely bypasses the package and module system. Unlike require, it does not perform any path searching and does not automatically adds extensions. libname must be the complete file name of the C library, including if necessary a path and extension. funcname must be the exact name exported by the C library (which may depend on the C compiler and linker used).
This function is not supported by ANSI C. As such, it is only available on some platforms (Windows, Linux, Mac OS X, Solaris, BSD, plus other Unix systems that support the dlfcn standard).
package.loadlib(libname,funcname)
Parameters
libname: (string) name of the library to load
funcname: (string) name of the function in library
