This document gives last minute information regarding the compiler. Furthermore, it answers frequently asked questions and gives solutions to common problems found with Free Pascal. The information presented herein always supersedes those found in the Free Pascal documentation.
For more comprehensive information on the pascal language, and the runtime library calls, consult the Free Pascal manuals. Topics covered in this document :
Originally named FPK-Pascal, the Free Pascal compiler is a 32 bit Turbo Pascal and Delphi compatible Pascal compiler for DOS, Linux, Win32, OS/2 and (based on an older version) the AmigaOS. More operating systems (BeOS and FreeBSD/ELF are in advanced stages of development) are in the works. A beta release for the PalmOS is available as well.
The compiler is written in Pascal and is able to compile its own sources. The source files are included.
Free Pascal is modest regarding its minimal system requirements (386-25 Mhz for the Intel version and ideally a 68020 processor for the Motorola version). At least 2 megabytes of RAM are required. To remake the compiler more than 16MB is recommended.
Short history:
FPC's version numbering changed a few times over the years. Versions before 0.99.5 are considered archaic. After the release of 0.99.5 a system in version numbering was introduced, and that system was changed slightly changed after the 1.0 release.
Versioning for versions 0.99.5 - 1.0Compilers with an even last number are release
versions (e.g. 0.99.8, 0.99.10, 0.99.12, 0.99.14 1.0.0)
Compilers and
packages with an odd last number are development versions
(e.g. 0.99.9, 0.99.11, 0.99.13, 0.99.15)
0.99.5 is an exception to this rule, since 0.99.5 IS a release (a release prior to the introduction of this odd/even system).
Letters behind the version number (0.99.12b, 0.99.5d) indicate release versions with some bugs and problems in the original release (respectively 0.99.12 and 0.99.5) fixed.
Versioning after 1.0
Together with the release of 1.0 the version numbering has been slightly changed, and a system in versioning resembling the Linux kernel's has been introduced. The main difference is that the difference between a release version is now in the second number (1.0.x vs 1.1.x) instead of the third number (0.99.14 vs 0.99.15), and the third number now becomes the patch level, replacing the postfixed letter in the old system.
Normally you would want to use a release. Releases are considered stable, and easier to support (the bugs, quirks and unintended "features" are well known after a period of time, and workarounds exist).
Development snapshots (which are generated daily) reflect the current status of the compiler. Development versions probably have new features and larger bugs fixed since the last release, but might have some temporary stability drawbacks (which are usually fixed by the next day).
Development snapshots are often quite useful for certain categories of users. Ask in the maillists if it is worth the trouble in your case if you're not sure.
We advise all users to upgrade to the newest version for their target. (1.0.8)
Applications created by the compiler and using the runtime library come under a modified library gnu public license (LGPL), which permit no restriction on the type of license the application has. It is therefore possible to create closed source or proprietary software using Free Pascal.
The compiler source code, on the other hand, comes under the GNU Public license, which means that any usage of the compiler source can only be used in software projects which have the same license.
The latest official stable Free Pascal release is available for download from all official mirrors
You are trying to login in to an ftp site. You must use the login name: anonymous and as your password, you should put your e-mail address.
The Free Pascal main ftp site can only accept a maximum number of simultaneous connections. If this error occurs, it is because this limit has been reached. The solution is either to wait and retry later, or better still use one of the Free Pascal mirror sites.
The development of the IDE (integrated development environment) is not yet finished. However a working test version of the IDE is included with version 1.0.x and higher of the compiler. There might be problems running the DOS IDE under Windows NT and Windows 2000 (especially the debugger), in that case it is suggested to use the native Windows version.
In the time between the release of new official versions, you can have a look at and test developer versions (so-called "snapshots"). Be warned though: this is work under progress, so in addition to old bugs fixed and new features added, this may also contain new bugs.
Snapshots are generated automatically each night from the current source at that moment. Sometimes this may fail due to bigger changes not yet fully implemented. If your version doesn't work, try again one or two days later. You're advised not to download the GO32v1 version for Dos, since it's not supported any more.
The latest snapshot can always be downloaded from the web page.
To install a snapshot, extract the zip archive into the existing program directory of the last official version of Free Pascal (after making a backup of the original of course). You can also extract it into an empty directory and then move the files to the program directory, overwriting existing files.
Make sure that you extract the ZIP archive such that the included directory structure remains intact. For example if you use PKUNZIP, use "pkunzip -d" instead of just "pkunzip". Note that snapshots also contain a new RTL which most likely can't be used with the previous release version, so backup your old RTL as well.
Go to the bugs page.
If you wish to know the bugs for a specific Free Pascal version, go to the bugs page, display the bug database. At the end of the page you should see an option to view only specific bugs. Choose "With Version" with the version you want to get information about and "With Status" choose "Unfixed". This should display all bugs which are present in the specific version of the compiler you requested.
No. Please, don't send us mail about homework, we are no teachers. The Free Pascal development team tries to give good support for the Free Pascal compiler and are trying to always reply to emails. If we get emails like this, this becomes harder and harder.
gdb(pas)(w) --directory=<src dirs> myprog.exeNotes:
info line *<address>For example:
info line *0x05bd8
By default Free Pascal allocates a small part of RAM for your application as heap memory. If it just allocated all it could get, people running Windows would have problems as Windows would increase the swap file size to give the program more memory on and on, until the swap file drive would be full.
You can specify the size of the heap with -Chxxxx.
However, the heap size doesn't really matter, since the Heap is able to grow: if you've used all the available heap space, the program will try to get more memory from the Operating system (OS), so the heap is limited to the maximum amount of free memory provided by the OS.
It is only handy if you know you will need at least a certain amount of memory. You can then specify this value using the -Ch parameter, so your program will allocate it at once on startup. This is slightly faster than growing the heap a number of times.
This sometimes happens with installation/compilation scripts if the copying command doesn't preserve dates. The object files get older than the PPU file, and the compiler tries to recompile them. A simple touch will solve it.
There are several reasons and remedies for this:
You can create smartlinked applications. To turn on the generation of smartlinkable units, use the -Cx command line option when compiling your units. To turn on the linking of previously generated smarlinkable units, use the -XX (-XS in 0.99.12 and earlier) command line option when compiling a program.
Starting from version 1.0.6 of Free Pascal, the configuration file is now called fpc.cfg instead of ppc386.cfg. For backward compatibility , ppc386.cfg is still searched first and, if found, is used instead of fpc.cfg
Versions prior to Free Pascal 1.0.6 do not recognize fpc.cfg, so if you wish to use an earlier version of the compiler using the same configuration file used with FPC version 1.0.6 (or later), the configuration file should be renamed to ppc386.cfg
.When there is abnormal termination of an application generated by Free Pascal, it is very probable that a runtime error will be generated. These errors have the form :
Runtime error 201 at 0x00010F86 0x00010F86 main, line 7 of testr.pas 0x0000206D
The 201 in this case indicates the runtime error number. The definition of the different runtime error numbers is described in the Free Pascal user's manual, Appendix D. The hexadecimal numbers represent the call stack when the error occured.
To see the list of base units supplied with Free Pascal, and on which platform they are supported, consult the Free Pascal user's manual. There is also a short description of what each unit does in the same section of the manual.
A draft document describing the internals of the FreePascal compiler is available here.
Debugging smart linked code might not work correctly. This is due to the fact that no type information is emitted for smartlinked code. If this would not be done, the files would become enormous.
While debugging, it is not recommended to use the smartlinking option.
Debugging shared libraries (or dynamic linked libraries) produced by the Free Pascal compiler is not officially supported.
Sometimes, even though there is a binary version of a module (unit file and object file) available, the compiler still gives compilation errors. This can be caused either by an incompatibility in the PPU file format (which should change only between major versions of the compiler), or by a change in one of the units of the RTL which has changed in between releases.
To get more information, compile the code using the -va (show all information) compiler switch, and the unit loading phase will be displayed. You might discover that the unit being loaded requires to be recompiled because one of the unit it uses has changed.
So if you plan on distributing a module without the source code, the binaries should be compiled and made available for all versions of the compiler you wish to support, otherwise compilation errors are bound to occur.
In other words, the unit (PPU) file format does not change significantly in between minor releases of the compiler (for exemple : from 1.0.4 and 1.0.6) which means they are binary compatible, but because the interface of the units of the RTL certainly changes between versions, recompilation will be required for each version anyways.
Trying to open files using reset on non-text files
might cause a Runtime Error 5 (Access denied).
All files opened using the above system unit routine use the current
filemode value to determine how the file is opened. By
default, filemode is set to 2 (Read/Write access).
So, a call to reset on non-text files does not
indicate that the file will be opened read-only. So, trying to open a file
using reset with the defaults will fail on read-only files.
filemode should be set to 0 (Real-only access) before
calling reset to solve this problem. A sample solution
is shown below.
const
{ possible values for filemode }
READ ONLY = 0;
WRITE ONLY = 1;
READ WRITE = 2;
var
oldfilemode : byte;
f: file;
begin
assign(f,'myfile.txt');
oldfilemode := filemode;
{ reset will open read-only }
filemode := READ ONLY;
reset(f,1);
{ restore file mode value }
filemode := oldfilemode;
...
close(f);
end;
For more information, consult the Free Pascal reference manual
Because the compiler now supports processors other than the Intel, it is important to take a few precautions so that your code will execute correctly on all processors.
Because the compiler supports several different operating systems, is important to take a few precautions so that your code will execute correctly on all systems.
The compiler supports the Delphi classes. Make sure you use the -S2 or -Sd switches (see the manuals for the meaning of these switches). For a list of Delphi incompabilities also check the manual.
It works like in Turbo Pascal. The first keyword in the file must be UNIT (not case sensitive). The compiler will generate two files: XXX.PPU and XXX.O. The PPU file contains the interface information for the compiler and the O-file the machine code (an object file, whose precise structure depends on the assembler you used). To use this unit in another unit or program, you must include its name in the USES clause of your program.
To recompile the system unit, it is recommended to have GNU make installed. typing 'make' in the rtl source directory will then recompile all RTL units including the system unit. You may choose to descend into the directory of your OS (e.g. rtl/go32v2) and do a 'make' there.
It is possible to do all this manually, but you need more detailed knowledge of the RTL tree structure for that.
function overloading is implemented, like in C++:
procedure a(i : integer);
begin
end;
procedure a(s : string);
begin
end;
begin
a('asdfdasf');
a(1234);
end.
You must be careful. If one of your overloaded functions is in the interface part of your unit, then all overloaded functions must be in the interface part. If you leave one out, the compiler will complain with a 'This overloaded function can't be local' message. Overloaded functions must differ in their parameters, it's not enough if their return types are different.
It is possible to call functions coded in C, which were compiled with the GNU C compiler (GCC). Versions which have been tested are version 2.7.2 through 2.95.2 of GCC. For calling the C function strcmp declare the following:
function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;
The default assembler syntax (AT&T style) is different from the one in Borland Pascal (Intel style).
However, as of version 0.99.0, the compiler supports Intel style assembly syntax. See the documentation for more info on how to use different assembler styles.
A description of the AT&T syntax can be found in the GNU Assembler documentation.
System (syslinux - not the bootloader, sysos2 or syswin32, depending on platform) is Pascal's base unit which is implicitely used in all programs. This unit defines several standard procedures and structures, and must be found to be able to compile any pascal program by FPC.
The location of the system.ppu and syslinux.o files are determined by the -Fu switch which can be specified commandline, but is usually in the ppc386.cfg or fpc.cfg configuration file.
If the compiler can't find this unit there are three possible causes:
A handy trick can be executing "ppc386 programname -vt", this shows where the compiler is currently looking for the system unit's files. You might want to pipe this through more (Dos, OS/2, Windows) or less (Linux), since it can generate more than one screen information:
Dos, OS/2, Windows: ppc386 programname -vt |more
unix, linux: ppc386 programname -vt |less
Since version 1.0, we have a completely platform independent way of selecting resolutions and bitdepths. You are strongly encouraged to use it, because other ways will probably fail on one or other platform. See the documentation of the graph unit for more information.
If you use detect as graphdriver, you will end up with the highest supported bitdepth. Since the graph unit currently only supports up to 16 bits per pixel modes and since this bitdepth is supported by all graphics cards made in at least the last 5 years, you will most likely get a 16 bit mode.
The main problem is that in 16 (and 15, 24, 32, ...) bit modes, the colors aren't set anymore using an index in a palette (the palettized way is called "indexed color"). In these modes, the color number itself determines what color you get on screen and you can't change this color. The color is encoded as follows (for most graphics cards on PC's at least):
This means that either you have to rewrite your program so it can work with this so-called "direct color" scheme, or that you have to use D8BIT as graphdriver and DetectMode as graphmode. This will ensure that you end up with a 256 (indexed) color mode. If there are no 256 color modes supported, then graphresult will contain the value GrNotDetected after you called InitGraph and you can retry with graphdriver D4BIT. Make sure you use the constant names (D8BIT, D4BIT, ...) and not their actual numeric values, because those values can change with the next release! That is the very reason why such symbolic constants exist.
The standard runtime library file I/O routines open files in the default sharing mode of the operating system (system, objects units). Because of this, you might get problems if the file is opened more than once either by another process or the same process.
Generally the behaviors for the different operating systems are as follows :
There are two ways to solve this problem:
The runtime library currently limits access to files which have file sizes which fit into a 32-bit signed integer (longint).
Therefore accessing files which have file sizes greater than 2 Gigabytes will produce unpredictable behavior. Application accessing such files will have to use direct operating systems calls (if the OS supports such files) to workaround the problem.
A Turbo Vision port, called Free Vision, has progressed nicely lately. It's already very usable, we are even writing an IDE in it. When it will be in a more stable state it will be included in the standard runtime library.
The GNU debugger v4.16 and later have been tested, and generally work as they should. Because the GNU debugger is C oriented, some pascal types might not be represented as they should. It is suggested to use gdbpas or the text mode IDE instead of GDB, which are both available for the DOS target.
Creation or use of shared libraries (also called dynamic link libraries) is not supported under this platform.
Profiling with gprof is supported for this platform.
On the Intel version the emulator is automatically loaded by the compiler if you add the following commands to your autoexec.bat:
SET 387=N SET EMU387=C:\PP\BIN\GO32V2\WEMU387.DXE(don't forget to replace the C:\PP with the directory where you installed FPC)
Trying to run an application which does floating point operations on a 386 system without a math co-processor will crash unless the emu387 unit is used, as this unit loads the math co-processor emulator (called wmemu387.dxe). You can add the unit as follows:
program myprog; uses emu387, ...
When the application is released, the software package should also include the wmemu387.dxe redistributable file to avoid problems.
.Some 80386 systems have a hardware bug which corrupt the accumulator register EAX if it is used in a MOV instruction just after a POPAL instruction. Prior to version 1.0.5, the compiler and runtime library could generate such code sequences. This is now fixed and should no longer cause problems
A lot of DOS mouse drivers don't support mouse cursors in VESA modes properly. Logitech is said to have a decent mouse driver, which can be found here
With versions before 0.99.10: if you're under DOS you can use the outport* and inport* procedures of the go32 unit.
Since version 0.99.8, the Port array is supported like in TP, as long as you use the ports unit in your program (not available under Win32).
I/O port access is possible under Linux, but that requires root privileges. Check the manuals for the IOPerm, ReadPort and WritePort procedures. (Unit Linux)
You can do like in Turbo Pascal, via absolute or mem[]. For larger memory blocks use the dosmemput/dosmemget routines in the Go32 unit.
Under the DOS (GO32V2) target, the default stack size to 256 bKbytes. This can be modified with a special DJGPP utility called stubedit. It is to note that the stack may also be changed with some compiler switches, this stack size, if greater then the default stack size will be used instead, otherwise the default stack size is used.
OS/2 applications (including the compiler) should work correctly under vanilla DOS, since it is based on EMX (versions prior to 1.0.5 had big problems with EMX under DOS, this is now fixed). It is important to note that the compiled applications require the EMX runtime files (emx.exe) to execute properly. It may be necessary to distribute these files with the generated application.
There is no special requirements for releasing software for the windows platform, it will work directly out of the box. The following are default for the Windows platform:
The GNU debugger v4.16 and later have been tested, and generally work as they should. Because the GNU debugger is C oriented, some pascal types might not be represented as they should. It is suggested to use gdbpas or the text mode IDE instead of GDB, which are both available for windows targets.
Creation and use of shared libraries (also called dynamic link libraries) is fully supported by the compiler. Refer to the Programmer's Reference Manual for more information on shared library creation and use.
Profiling is supported using gprof, starting with version 1.0.7. It requires mingw to be installed, and that fpc.cfg point to the correct library paths.
Problem:
Problem:
{$apptype GUI}
and put this line before your programs InitGraph statement:
ShowWindow(GetActiveWindow,0);This will hide the dos window window.
Some of the demos (like fpctris) use these techniques
After the 1.0.4 release, some problems with the mingw win32 build tools (make.exe and friends) were discovered. A patched version of these tools has been released. Automatically building large parts of the sources under Windows 2000 and Windows NT is now a lot easier.
Alternatively, if changing the case of the "Path" variable leads to problems, you could run the following batchfile in each dosbox prior to working with FPC:
set a=%PATH% set Path= set PATH=%A% set a=
A lot, if not all, makefile trouble is now probably gone. If you still have problems try getting the makent.zip utilities from the ftp site or a mirror. It should be installed just like makew32.zip.
Note: The win32 version of make is case sensitive with respect to filenames (paths?) and environment variables
There is a problem with the DOS (GO32V2) compiler and Windows 95 on computers with less than 16 Megabytes of RAM. First set in the properties of the DOS box the DPMI memory size to max value. Now try to start a demo program in the DOS box, e.g. HELLO (starting may take some time). If this works you will be able to get the compiler to work by recompiling it with a smaller heap size, perhaps 2 or 4 MB (option -Chxxxx).
Normally OS/2 applications (including the compiler) should work under Windows, since it is based on EMX. You need the RSX extender (rsx.exe) to do this. There have been problems reported while trying to run EMX applications under NT / 2000 / XP systems though. This seems to be a problem with EMX (RSX) itself. It is not recommended to use Free Pascal OS/2 compiled programs under NT / 2000 and XP, as it might produce unexpected results.
Several problems have been found running DOS software under certain versions of Windows (NT / 2000 / XP). These seem to be problems with the DOS emulation layers (emulated DPMI services). These problems may not occur with all software generated by FPC. Either applications should be tested on these systems before being released, or Windows versions should be generated instead.
In windowed mode, the mouse cursor might not respond to mouse moves and clicks. Just change the properties of the console, and remove the quick edit mode option. This should solve the mouse response problems.
The original 1.0.6 installer gave errors under Win95/98/Me in some circumstances. A new installer (INSTALL.EXE) was included after the 10th July 2002 which fixed the problem.with version 1.0.6. If you downloaded Free Pascal for Windows before this date, you should upgrade to the latest version of FreePascal.
This section also applies to most unix variants, such as linux, freebsd and netbsd.
The GNU debugger v4.16 and later have been tested, and generally work as they should. Because the GNU debugger is C oriented, some pascal types might not be represented as they should. For FreeBSD a recent GDB (v5) CVS snapshot is recommended for Pascal support and ease of building
These operating systems do support shared libraries (also called dynamic link libraries), Free Pascal currently does not emit position independant code (PIC), as required for the creation of shared libraries.
Therefore, even though the linux compiler target permits creating shared libraries, the usage of that shared library may result in undefined behavior, especially if accessing global variables in the library. Creation of shared libraries is not recommended with the current version of the compiler.
Importing code from shared libraries does work as expected though, since it does not require usage of position independant code.
Profiling is supported using gprof under linux, FreeBSD and NetBSD, the latter two only since 1.0.8. On other other unix-like operating systems, profiling is currently not supported.
This error typically looks like this:
Free Pascal Compiler version 1.0.x [xxxx/yy/zz] for i386 Copyright (c) 1993-2000 by Florian Klaempfl Target OS: Linux for i386 Compiling test.pp Assembling test Linking test /usr/bin/ld: cannot find -lvga test.pp(6,4) Warning: Error while linking Closing script ppas.sh 5 Lines compiled, 0.2 sec
This error is not an error in the installation of FPC or FPC itself, but a missing Svgalib library in your unix install. Please install the required library using your favourite package manager tool
Normally unix systems have the assembler (as) and linker (ld) pre-installed and already in the search path. That is the reason why these tools are not supplied with the compiler.
If the compiler cannot find these tools, either they are not in your search path, or they are not installed. You should either add the path where the tools are located to your search path, and / or you should install these tools.
It is to note that the Solaris version of FPC contains these tools.
The OS/2 compiler is based on EMX, therefore it should work both on OS/2 and on vanilla DOS systems.
The GNU debugger v4.16 (EMX port) has been tested (including its PM add-on, pmgdb.exe) and generally works as it should. Because the GNU debugger is C oriented, some pascal types might not be represented correctly.
Even though this operating system permits the creation and usage of shared libraries (also called dynamic link libraries), the compiler currently only permits importing routines from dynamic libraries (creation of dynamic libraries is unsupported).
Profiling is currently not supported for this platform.
It has been reported that some DOS (GO32V2) applications (including the DOS compiler itself) generated by the compiler fail on some OS/2 installations. This is due to problems in the OS/2 DPMI server.
You should use native OS/2 applications under OS/2 (including the native OS/2 compiler) or try installing a new OS/2 fixpack to see if it solves the problem.
or
You are most probably using an older version of OS/2 (like OS/2 Warp 3.0) and don't have TZ variable in your environment. The easiest solution is to add "SET TZ=..." (e.g. "SET TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600" for most of western and central Europe) line to your CONFIG.SYS, and restart OS/2. The proper setting for you can be found e.g. using the TZCALC tool from TIME868 package.
Software generated for the BeOS target will only work on the intel based version of BeOS.
This operating system uses DWARF debugging information, and Free Pascal does not support emitting DWARF debugging information. It is currently impossible to debug applications under BeOS
Even though this operating system permits the creation and usage of shared libraries (also called dynamic link libraries), the compiler currently only permits importing routines from dynamic libraries (creation of dynamic libraries is unsupported).
Profiling is currently not supported for this platform.
Source level debugging is not supported for the Amiga target. Assembler target debugging is possible though, using the excellent Barfly debugger.
Even though this operating system permits the creation and usage of shared libraries (also called dynamic link libraries), the compiler does not support either the importing or creation of shared libraries. Importing must be done manually in assembler.
Profiling is currently not supported for this platform.