-> freepascal libraries

library librarytest; { It will generate the file "liblibrarytest.so" }

procedure Hello; { It doesn't need the "export" directive } begin 
WriteLn('Hello!'); end;

exports { It really exports the procedures and functions } Hello;

begin end.

Now the application that uses the librarytest:

program applicationtest; { It will generate the file "applicationtest" }

{ This directive below will link this application dynamiclly with the 
shared object liblibrarytest.so }

{$LinkLib librarytest}

procedure Hello; { No implementation nor special declaration }

begin Hello; { It's very simple, isn't? } end.
You must to know that the search path for shared objects is the 
directory list declared in the LD_LIBRARY_PATH environment variable and 
not in the PATH, nor in
the current directory (like MS Windows).

You may type just "set" to see the environment variable list. You'll see 
the LD_LIBRARY_PATH in the list.

Note that the directory list separator isn't the ';' character like in 
DOS or MS Windows plataforms. In linux, the directory list separator is 
the ':' character. (/blabla1:/blabla2:/blabla3)

Now I don't remember the name of the linux configuration text file where 
the LD_LIBRARY_PATH environment variable is defined, but you can to copy 
or to move your shared objects to one of the directories of that 
directory list.

-> About glibc...
quote from freepascal.org discussion


Some day ago I use Kylix to do something, and I found that it use a 
'Libc' unit
to do the system call and something else.
But I also found that freepascal do these by itself! And I do NOT think 
it a good idea, first, we MUST do more things that have been done, 
second, the Kernel also depent on the glibc, but we do something by 
ourselves, will someting wrong because this?

I want to know how do you think it...

cheers to Pascal!

baldzhang@netease.com

-- Bald Zhang, August 24, 2001

Answers
1. The kernel does NOT depend on glibc; it is the other way round.
2. We want to be independent of any C library because if it changes, we 
must change with it. Any bugs in Libc would also be in FPC.
3. It's faster this way.

4. There will be a 'posix' port which will use only POSIX stuff, for 
easy porting. That one will necessarily depend on Libc; you can always 
use that one when it appears.

-- Michael Van Canneyt, August 24, 2001

Another main reason is distribution. FPC Pascal is not in every 
distribution (and neither is Kylix), so a source based distribution 
system like C sources on most Unix systems is not so easy.
Kylix avoids this by only supporting a small subset of distributions. 
FPC doesn't want to go this way. We support Linux, not a few commercial 
distro's

IOW using the kernel directly instead of via libc makes distribution 
independant support for a lot of programs easier.
-- Marco van de Voort, August 27, 2001



-> List of files:

Program DisplayFiles;

USES Dos;

VAR Directory: SearchRec;
BEGIN

FIndFirst('a:*.*', archive, Directory);
WriteLn('FileName'+Space(32), 'FileSize':9);
WHILE (DosError = 0) DO
BEGIN
WriteLn(Directory.Name+Space(40-Length(Directory.Name)), 
Directory.Size:9);
FineNext(Directory); END;
FindClose(Directory);
END.

-> Dinamic array in FPC
In early versions of fpc and turbo pascal dynamic arrays was not implemented, so this is a solution:

p : ^integer; begin getmem(p,10);
here we have created an array with 5 integers (2 bytes per integer)

you can access to the first with p^, the second (p+1)^ and so on