Provided by: libgii0_0.9.1-0.1ubuntu1_i386
libgg : Handy, portable wrappers for several basic OS features
LibGG provides a portable, unified interface to various very basic
operating system features, making it easy to write portable programs
without locking the author into a restricted, bloated, or overbearing
development paradigm. By abstracting the most commonly used
functionality in an operating-system-independent fashion, relying on
prepackaged LibGG distributions can also can reduce the complexity
involved in maintaining a portability suite (e.g. autotools) for the
Originally LibGG came into being as part of the GGI Project, when
LibGII input functionality was separated from LibGGI into a stand-alone
library, and a place was needed to put functions needed by both
libraries. (Since then, we have forgotten what "GG" stood for, so
The master upstream source of LibGG is still distributed as part of
LibGII, however it is itself a separately-distributable stand-alone
package of utilities that can be very useful to applications
LibGG provides the following groups of functions and/or macros. Some
may not be possible to implement on some operating systems, some may be
possible, just nobody has done so yet. We try to make them all
available where we can find the time and expertise:
Time functions (ggCurTime(3), ggUSleep(3) and ggUSlumber(3)) to handle
high-resolution timing and delays without busy-looping.
Cleanup callbacks (ggRegisterCleanup(3), ggUnregisterCleanup(3),
ggCleanupForceExit(3)) to allow your application to perform emergency
actions before a program is terminated abnormally.
Timer callbacks (ggAddTask(3), ggDelTask(3), ggTimeBase(3)) provide a
(non-realtime) wall-clock periodic/one-shot callback scheduler that can
be shared between many different areas of the application code without
fear of interference.
Locking Functions (ggLock(3), ggLockCreate(3), ggLockDestroy(3),
ggTryLock(3), ggUnlock(3)) which are thread-safe in threaded
System and CPU detection utilities (ggGetSwarType(3), GG_HAVE_INT64,
GG_LITTLE_ENDIAN) to allow you to detect CPU endianness and the
presence of features such as SWAR (SIMD) instruction sets (e.g. MMX),
and to turn on/off or change SWARs for testing or as a workaround.
Very basic overrun-proof string operations (ggstrlcpy(3), ggstrlcat(3))
which are a horrible mess for cross-platform programs to map to OS-
local string functions/headers.
Pluggable module management functions (ggLoadModule(3), ggMLoadModule,
ggGetSymbolAddress(3), ggFreeModule(3)) that allow you to create a
plug-in system where code is dynamically loaded into and out of your
program. (Support for statically linked emulation for embedded systems
is also provided.)
An option parser (ggParseOpts, ggSystemOpts) and plugin configuration
system (ggGetUserDir(3), ggParseTarget, ggLoadConfig, ggFreeConfig,
ggMatchConfig, ggConfigExpandAlias) which are by-products of the
pluggable module support but can be useful for other things if you like
LibGG uses the environment variable $GG_OPTS, and expects it to contain
a valid option string as documented in the manpage for ggParseOpts.
The available options are documented along with the LibGG API functions
which they most affect.
LibGG requires the exclusive use of one signal under certain
environments. This signal defaults to SIGPROF, where available, but
may be configured through the GG_OPTS option "-signum=n" where n
represents the numerical value of the signal to use. This signal
should not be one of the fatal signals handled by the LibGG cleanup
facilities, and must be a signal onto which a handler may be assigned.
Applications should not install handlers or alter the signal handler in
any way for this signal.
There is still some legacy to LibGGI in some of the namespace,
especially GGI_LITTLE_ENDIAN is currently the real name for
GG_LITTLE_ENDIAN, which is an unofficial new addition destined to
replace it. Deprecation will take a few revisions as it must be done
in an orderly fashion.
Likewise the header file is included as <ggi/gg.h> but we will probably
keep that as-is because of the way LibGG is distributed and to avoid
adding more clutter in system include directories than is necessary.
Several features are incomplete, for example, code is still needed to
detect SWAR on many of the more obscure architectures.