WWW-www.enlightenment.org pushed a commit to branch master.
http://git.enlightenment.org/website/www-content.git/commit/?id=f06eb8cf1eeb35c9a8a15e50aa1ca8e3b87e394a
commit f06eb8cf1eeb35c9a8a15e50aa1ca8e3b87e394a
Author: Raster <ras...@rasterman.com>
Date: Sun Jun 21 22:37:30 2015 -0700
Wiki page start changed with summary [] by Raster
---
pages/docs/c/start.txt | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/pages/docs/c/start.txt b/pages/docs/c/start.txt
index 6f7d398..8dee97f 100644
--- a/pages/docs/c/start.txt
+++ b/pages/docs/c/start.txt
@@ -538,8 +538,33 @@ Pkg-config relies on setting your ''PKG_CONFIG_PATH''
environment variable to in
Add as many directories as you like with a '':'' character between them. They
will be searched in order from the first to last, until a matching ''.pc'' file
is found.
==== API calls ====
+
+A library (or in fact any part of a program can too) exports API calls. These
are mostly actual function calls, with the prototypes (telling the compiler the
function name, what it returns and what it accepts as parameters) in the header
files. The headers may also provide macros to use and perhaps also global
variables. When an application runs, it's the functions and variables that
matter. These are exposed as "symbols".
+
+Symbols are listed as strings in a symbol table. This could be thought of as
an array of strings, with locations where that function (or variable) is stored
in the library. At runtime, libraries are linked and these symbols are looked
up, with pointers to these functions being "fixed up" by the runtime linker. If
a symbol is missing in a library that something else needs, you will get a
runtime linking error (and generally execution stops here before even main() is
called).
+
+If the types that a function returns or accepts changes, then there is an ABI
(Application Binary Interface) break. Libraries should never do this without
also jumping up a major version e.g. from 1.x to 2.0, or 2.x to 3.0 etc. This
major version change indicates that there is a break in ABI (or API). On Linux
you will see the version of the library in its filename:
+
+ libeina.so.1.4.99
+
+For example. When compiling, the compiler looks for a file called
''libeina.so'' in the link search path (usually ''/lib'' and ''/usr/lib'',
unless you also add directories with ''-L'' such as ''-L/usr/local/lib''). If
this file (''libeina.so'') is a symbolic link (symlink), this is dereferenced.
Generally this is the symlink setup used for shared libraries:
+
+^File ^ ^Link ^
+|//libeina.so// | => |//libeina.so.1// |
+|//libeina.so.1// | => |//libeina.so.1.4// |
+|//libeina.so.1.4// | => |//lineina.so.1.4.99// |
+|**libiena.so.1.4.99** | | |
+
+After this dereferencing, the compiler will embed into the binary being
compiled the need to link to ''libiena.so.1''. If this doesn't exist anywhere
in the runtime search path (which is different to the compile time one - this
is normally ''/lib'' and ''/usr/lib'' and ''/etc/ld.so.conf'' can extend this
list, as well as the ''LD_LIBRARY_PATH'' environment variable can set the
search path at runtime something like ''/usr/local/lib:/usr/lib:/lib'' which
would mean to look in ''/usr/local/ [...]
+
+It is also possible to manually load a shared object file (thus the ''.so''
extension) manually using calls such as ''dlopen()'' and ''dlsym()''. This will
led you load a shared object file and manually look for specific symbols in the
file and get a pointer per symbol. This is often a way API/ABI calls are found
from modules.
+
+The difference between ABI and API is that API covers the interface in general
both at compile AND at runtime, but ABI is specifically post-compilation at
runtime. If ABI stays the same, but API changes, then existing binaries will
keep working fine. If you wish to adapt to the new API you will need to
recompile and possibly change some of your code to adapt to these changes.
+
==== System calls ====
+
+
----
==== Endianess ====
--
