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 16,32 and 64 bit Turbo Pascal and Delphi compatible Pascal compiler for Linux, Windows, OS/2, FreeBSD, Mac OS X, DOS and several other platforms (the number of supported targets grows all the time, although not all of them are on the same level as the main ones).
The Free Pascal compiler is available for several architectures: x86 (16,32 and 64 bit), ARM, PowerPC (32 and 64 bit), SPARC (v8, v9), Java Virtual Machine (under development) and MIPS (little and big endian, under development). An older version (the 1.0 series) and current development versions also supported m68k.
The compiler is written in Pascal and is able to compile its own sources. The source files are distributed under the GPLv2+ and included.
Short history:
The latest official version is 3.0.4, the third release in the 3.0.x series. New development is performed in the 3.1.x series, which will eventually be released as 3.2.0 or 4.0.0, depending on milestones achieved.
FPC's version numbering changed a few times over the years. Pre-1.0 versioning information has been moved to the Wiki 1.0 versioning article.
With the release of 1.0, the version numbering was slightly changed to a system resembling one used for the Linux kernels.
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 on the mailing lists if it is worth the trouble in your case if you are not sure.
Snapshots of the stable branch (fixes_3_0) are meant to test release engineering. They are mainly interesting in the months before a release to extensively test the branch from which the release is created.
We advise all users to upgrade to the newest version for their target (preferably the new stable 3.0.x series).
A graphical timeline of the FPC project plus its near future would be:
Applications created by the compiler and using the runtime library (RTL) come under a modified Library GNU Public License (LGPL). This license does not impose any kind of license on the created applications. It is therefore possible to create closed source or proprietary software using the Free Pascal Compiler.
The following exception has been added to the LGPL variant that applies to the FPC RTL:
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
Please note that you still have to comply to the LGPL as far as sources of the runtime library itself are concerned. This, for example, requires you to provide the source code of the runtime library if a recipient of your application asks for it. If you want to write proprietary closed source software, please comply with the following terms:
The compiler source code, on the other hand, comes under the GNU General Public License, which means that the compiler source can only be used in software projects that are distributed under a compatible license (or that are not distributed at all).
The latest official stable Free Pascal release is available for download from all official mirrors
You are trying to login to an ftp site. You have to use the login name "anonymous" and your e-mail address as your password.
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.
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 in 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 does not work, try again one or two days later.
The latest snapshot can always be downloaded from the development 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.
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.
If you want a start, please start to study JEDI-SDL or PTCPas. Also you can try to study an existing game, for example The Sheep Killer is a very simple game and it should not be very hard to understand its code.
gdb --directory=<src dirs> myprog.exeNotes:
info line *<address>For example:
info line *0x05bd8
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.
Also note that FPC, contrary to Turbo Pascal keeps track of include files. Modified include files or duplicate names can trigger an attempt to recompile.
When an application generated by FPC terminates in an abnormal way, it is very likely that a runtime error will be generated. These errors have the form :
Runtime error 201 at $00010F86 $00010F86 main, line 7 of testr.pas $0000206D
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 addresses on 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.
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.
Sometimes, even though there is a binary version of a module (unit file and object file) available, the compiler claims it cannot find the unit This can be caused either by an incompatibility in the PPU file format (which can change across compiler versions), or by a change in one of the units of the RTL that has changed in between releases.
To get more information, compile the code using the -vtu (show tried and used unit 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.
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.
GNU-Pascal is however a modern compiler that can compile ISO Extended Pascal. If you have any need for the ISO Extended Pascal dialect, we recommend you to take a look at this compiler.
Mainly the users are either interested because of .NET's portability aspects (Mono is quoted over and over again), or because it is supposed to be the next big thing in Windows programming, and they think Windows programming will not be possible in the future.
While the FPC core developpers are somewhat interested out of academic curiousity (mainly because it could be a pilot for a generalized backend creating bytecode) there are however several problems with .NET in combination with FPC:
So effectively this means that for FPC to benefit from .NET you would have to significantly adapt the language (thus compiler) and libraries, and be incompatible with the existing native sourcecode. Moreover that also means that existing apps would have to be rewritten for .NET, since it would take more than a simple recompile with a FPC/.NET compiler.
While unmanaged code has some uses (easier integration with managed code inside Windows), this still requires writing a code generator and defining interfaces and libraries. This means a lot of work and since .NET take-up is not really high, this might not be worth it.
However if a FPC user does the bulk of the work (e.g. a bytecode codegenerator, and maybe some base libraries) and if the work is suitable for inclusion in FPC (a very big if), we will of course include it.
Since support for generating JVM bytecode has been added to the compiler, such a project may be more realistic now than it has been in the past. Many of the caveats mentioned above still hold though: language compatibility is not 100% and most standard units will have to be reimplemented.
Because the compiler supports multiple processor architectures, it is important to take a few precautions so that your code will execute correctly on all processors.
FPC_LITTLE_ENDIAN
or FPC_BIG_ENDIAN
to indicate the
target endianness.
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 Delphi-style classes. Make sure you use the -S2 or -Sd command line switches (see the manuals for the meaning of these switches), or add {$mode objfpc} or {$mode delphi} to your source code. For a list of Delphi incompatibilities 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/linux) 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.
Here is a procedure overloading example in FPC or ObjFPC mode:
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 is not enough if only their return types are different.
It is possible to call functions written in C and compiled by the GNU C compiler (GCC). E.g., for calling the C function strcmp, declare the following (the cint type is declared in the ctypes unit):
function strcmp(s1 : pchar;s2 : pchar) : cint;cdecl;external;
The default assembler syntax (AT&T style) is different from the one in Borland Pascal (Intel style). FPC however supports both styles. 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 is Pascal's base unit and is implicitly used by 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 and other unit files is passed on to the compiler by the -Fu switch. This switch can be specified on the command line, but is usually located in the fpc.cfg configuration file.
If the compiler cannot find this unit, there are three possible causes:
A handy trick can be executing "fpc programname -vtu". This will show where the compiler is currently looking for the unit files. You might want to pipe this through more (Dos, OS/2, Windows) or less (UNIX), since it can generate more than one screen information:
Dos, OS/2, Windows: fpc programname -vt |more
UNIX, Linux: fpc programname -vt |less
Besides these pre-selection rules and documentation, the other important question is who is going to do the work. Keep in mind that the FPC developers are volunteers with todo-lists that are booked till the next decade. You cannot expect they will drop everything from their hands and implement the feature because you need it urgently, or think it is nice. If you are not willing to implement it yourself, submit patches and maintain it in the future, chances are slim. Remarks as "this will attract a lot of users because..." are considered with a lot of scepsis, since that applies to any new development.
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 virtually all graphics cards, you will most likely get a 16 bit mode.
The main problem is that in 16 (and 15, 24, 32, ...) bit modes, the colors are not 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 not 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.
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:
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
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 v6.4 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 the text mode IDE instead of GDB, which is 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. It requires mingw to be installed, and that fpc.cfg points 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
The mingw make tool seems to look for a "sh.exe", which it finds when the cygwin binary directory is in the path. The way directories are searched changes, and the build process dies.
Solution: do not put cygwin in your global path for now, only add it when needed. Efforts are made to work around this.
Possible untested workaround: add mingw sh.exe to a directory before the cygwin binary directory in the path
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).
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 or the Go32 extender). 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 IDE 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.
This section also applies to most UNIX variants, such as Linux, FreeBSD and Mac OS X.
The GNU debugger v6.5 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.
Creating dynamic libraries under UNIX-like operating systems is supported.
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.
Libc is a Kylix compatibility unit. Because it contains many i386 specific code and features structures from legacy kernels, it has not been made available on other platforms.
To access UNIX functionality, please use units like baseunix and unix.
This error typically looks like this:
Free Pascal Compiler version 3.0.x [xxxx/yy/zz] for i386 Copyright (c) 1993-2008 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.
There is a bug in GNU LD 2.19 and 2.19.1 that causes it to crash when processing FPC-generated linker scripts. This bug has been fixed in the mean time.
At the same time, LD has been modified to emit a warning of the form
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
This warning is benign, and FPC intentionally does not pass -T to LD. The reason is that if -T is used, LD's internal linker script is ignored and only FPC's linker script is used. Such linker scripts also contain paths to libraries however, and if we would ignore the internal linker script then LD would no longer find libraries in distribution-specific directories.
The OS/2 compiler version 1.0.x and before is based on EMX, therefore it should work both on OS/2 and on vanilla DOS systems. In version 1.9.x and above this functionality is preserved in newly added target EMX, whereas binaries for target OS2 can only run under real OS/2. The following notes apply to OS2 target in 1.0.x and EMX in 1.9.x and above:
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.
You are most probably using an older version of OS/2 (like OS/2 Warp 3.0) and do not 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.
An updated version of GNU assembler (as.exe) is packaged with release 1.9.6 (newer version was necessary to get support for features of modern CPUs). This version of the GNU tool was created with Innotek port of GNU C and relies on its libc. This results in higher limitations regarding supported configurations, because this libc needs recent version of OS/2 Unicode support libraries (LIBUNI.DLL and UCONV.DLL) not available in base OS/2 Warp 3.0 and OS/2 Warp 4.0. The updated versions were distributed by IBM in corrective packages (fixpaks) - see e.g. WarpUpdates site for information about OS/2 fixpaks and links for downloading them. This issue isn't valid for WarpServer for e-Business, MCP and eComStation - these already have the correct version.
Apart from the point mentioned above, there is at least one more potential reason for issues with executing the assembler and resulting in error message "Can't call the assembler, error 2 switching to external assembling". This error may be result of the OS/2 system not being able to find DLLs required for the assembler. Make sure that you installed FPC completely (these DLLs are part of file asldos2.zip) and that you have set LIBPATH according to instructions in README.TXT (and restarted afterwards). If in doubts, running the assembler directly from the command line (e.g. "as --version" to show the installed as.exe version) may be helpful to see name of the missing dynamic library or other details about the problem.
Software generated for the BeOS target will only work on the Intel based version of BeOS.
Debugging works with the system-supplied gdb version.
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 certain versions of the linker that shipped with some versions of BeOS are broken. If you get an error when linking fpc applications, try updating your version of ld from the following site.
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 the text mode IDE instead of GDB, which is 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(do not forget to replace the C:\PP with the directory where you installed FPC)
Trying to run an application which performs 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
Many DOS mouse drivers do not properly support mouse cursors in VESA modes. Logitech is said to have a decent mouse driver, which can be found here
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.