/usr/share/doc/fp-compiler/2.6.4/faq.html is in fp-compiler-2.6.4 2.6.4+dfsg-4.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Free Pascal - Knowledge base</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EE" vlink="#551A8B" alink="#FF8080">
<h1>FAQ / Knowledge base</h1>
<p>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.
<p> For more comprehensive information on the pascal language, and the runtime library
calls, consult the Free Pascal manuals. Topics covered in this document :
<OL>
<li>General information
<OL>
<li><a href="#WhatIsFP">What is Free Pascal (FPC)?</a>
<li><a href="#versions">Which versions exist, and which one should I use?</a>
<li><a href="#FPandGNUPascal">Free Pascal and GNU Pascal - a comparison</a>
<li><a href="#general-license">License and copyright information</a>
<li><a href="#WhereToGetFP">Getting the compiler</a>
<li><a href="#general-install">Free Pascal installation hints</a>
<li><a href="#ftpproblems">Why do i have to supply a user name and password to get Free Pascal ?</a>
<li><a href="#general-connectftp">Access denied error when connecting to the Free Pascal FTP site</a>
<li><a href="#snapshot">I want a new version NOW</a>
<li><a href="#installsnap">Installing a snapshot</a>
<li><a href="#HOMEWORK">I have to write a program for homework. Can you help?</a>
<li><a href="#windowsapp">How do I make a real Windows application with windows and menu bars?</a>
<li><a href="#game">How do I make a game with Free Pascal? Can I make a game like Doom 3?</a>
<li><a href="#ErrorPos">Getting more information when an application crashes</a>
<li><a href="#general-heap">Increasing the heap size</a>
<li><a href="#general-doesntfindfiles">Compiler seems to skip files in directories -Fu points to</a>
<li><a href="#binariesbig">Why are the generated binaries so big?</a>
<li><a href="#cfgfiles">Configuration file problems (fpc.cfg or ppc386.cfg)</a>
<li><a href="#runerror">Runtime errors</a>
<li><a href="#stdunits">Standard units</a>
<li><a href="#debugsmart">Debugging smartlinked code does not fully work</a>
<li><a href="#debugshared">Debugging shared library (dynamic linked library) code does not fully work</a>
<li><a href="#cantfindunit">PPU files binary compatibility between versions</a>
<li><a href="#cantfindunit">Can't compile a program using a binary only version of a unit</a>
<li><a href='#isoxpascal'>Will you support ISO Extended Pascal?</a>
<li><a href="#dotnet">What about .NET?</a>
</OL>
<li>Pascal language related information
<OL>
<li><a href="#PortingCPU">Considerations in porting code to other processors</a>
<li><a href="#PortingOS">Considerations in porting code to other operating systems</a>
<li><a href="#OOP">Compiling Delphi code using Free Pascal</a>
<li><a href="#HowcanIbuildaunit">Building a unit</a>
<li><a href="#CompileSystemUnit">Compiling the system unit</a>
<li><a href="#Howdoesprocedureoverloadingwork">How does function overloading work?</a>
<li><a href="#HowToCallCFuncuntions">Calling C functions</a>
<li><a href="#IntegratedAssemblerSyntax">Integrated Assembler syntax</a>
<li><a href="#systemnotfound">Unit system not found errors</a>
<li><a href="#extensionselect">There is a new extension that will be really useful. Will you include it?</a>
</OL>
<li>Runtime library related information
<OL>
<li><a href="#HowToUseGraph">Using the graph unit with Free Pascal</a>
<li><a href="#WrongColors">Why do I get wrong colors when using the graph unit?</a>
<li><a href="#fileshare">File sharing and file locks</a>
<li><a href="#filemode">File denied errors when opening files with reset</a>
</OL>
<li>DOS related information
<OL>
<li><a href="#dos-release">Releasing software generated by the DOS compiler</a>
<li><a href="#dos-debugging">Debugging</a>
<li><a href="#dos-dll">Dynamic libraries</a>
<li><a href="#dos-profile">Profiling</a>
<li><a href="#FPwithoutfpu">Running Free Pascal without a math coprocessor</a>
<li><a href="#fp386">Applications created with Free Pascal crash on 80386 systems</a>
<li><a href="#nomousegraph">The mouse cursor is not visible in graphics screens</a>
<li><a href="#accessioports">Accessing I/O ports</a>
<li><a href="#HowToAccessDosMemory">Accessing DOS memory / Doing graphics programming</a>
<li><a href="#dos-stack">Changing the default stack size</a>
<li><a href="#dos-os2">Using OS/2 generated applications under DOS</a>
</OL>
<li>Windows related information
<OL>
<li><a href="#win-release">Releasing software generated by the windows compiler</a>
<li><a href="#win-debugging">Debugging</a>
<li><a href="#win-dll">Dynamic libraries</a>
<li><a href="#win-profile">Profiling</a>
<li><a href="#win-graph">Graph and problems with keyboard, mouse and "dummy dos windows"</a>
<li><a href="#win-cygwin">Cygwin binary directory in your path sometimes causes builds to fail</a>
<li><a href="#win95-fpc">Using the DOS compiler under Windows 95</a>
<li><a href="#win-os2">Using OS/2 generated applications under Windows</a>
<li><a href="#win-dos">Using DOS generated applications under windows</a>
<li><a href="#win-ide-mouse">The mouse cursor does not respond in the Windows IDE</a>
</OL>
<li>UNIX related information
<OL>
<li><a href="#unix-release">Releasing software generated by the unix compilers</a>
<li><a href="#unix-debugging">Debugging</a>
<li><a href="#unix-dll">Dynamic libraries</a>
<li><a href="#unix-profile">Profiling</a>
<li><a href="#libci386">Libc is missing on platforms other than i386</a>
<li><a href="#vgamissing">Why can't the linker find "vga"?</a>
<li><a href="#unix-asldmissing">Compiler indicates missing as and ld</a>
<li><a href="#unix-ld219">An error occurred while linking, or "did you forget -T?"</a>
</OL>
<li>OS/2 related information
<OL>
<li><a href="#os2-release">Releasing software generated by the OS/2 compiler</a>
<li><a href="#os2-debugging">Debugging</a>
<li><a href="#os2-dll">Dynamic libraries</a>
<li><a href="#os2-profile">Profiling</a>
<li><a href="#os2-dos">Using DOS generated applications under OS/2</a>
<li><a href="#instal106os2">INSTALL.EXE of version 1.0.6 or below returns an unknown error (-1) under OS/2</a>
<br>or<br>
<a href="#instal106os2">INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</a>
<li><a href="#os2-fp">OS/2 compiler not working after upgrading to 1.9.6 or newer</a>
<li><a href="#os2-as-failing">Compilation under OS/2 fails with error "Can't call the assembler"</a>
</OL>
<li>BeOS related information
<OL>
<li><a href="#beos-release">Releasing software generated by the BeOS compiler</a>
<li><a href="#beos-debugging">Debugging</a>
<li><a href="#beos-dll">Dynamic libraries</a>
<li><a href="#beos-profile">Profiling</a>
<li><a href="#beos-linking">BeOS linking problems</a>
</OL>
<li>Amiga related information
<OL>
<li><a href="#amiga-release">Releasing software generated by the Amiga compiler</a>
<li><a href="#amiga-debugging">Debugging</a>
<li><a href="#amiga-dll">Dynamic libraries</a>
<li><a href="#amiga-profile">Profiling</a>
</OL>
<li>PalmOS related information
<OL>
<li><a href="#palmos-release">Releasing software generated by the PalmOS compiler</a>
<li><a href="#palmos-debugging">Debugging</a>
<li><a href="#palmos-dll">Dynamic libraries</a>
</OL>
</OL>
<OL>
<li><h2>General information</h2>
<OL>
<li><a name='WhatIsFP'></a>
<h3>What is Free Pascal (FPC)?</h3>
<p>Originally named FPK-Pascal, the Free Pascal compiler is a 32
and 64 bit Turbo Pascal and Delphi compatible Pascal compiler for
DOS, Linux, Win32, OS/2, FreeBSD, AmigaOS, Mac OS X, Mac OS classic 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).
<p>The Free Pascal compiler is available for several
architectures: x86, Sparc (v8,v9), ARM, x86_64 (AMD64/Opteron),
PowerPC and PowerPC64. An older version (the 1.0 series) and
current development version also support m68k, the current development version also
supports MIPS (in both big endian and little endian modes).
<p>The compiler is written in Pascal and is able to compile its
own sources. The source files are under GPL and included.
<p>Short history:
<ul>
<li>06/1993: project start
<li>10/1993: first little programs work
<li>03/1995: the compiler compiles the own sources
<li>03/1996: released to the internet
<li>07/2000: 1.0 version
<li>12/2000: 1.0.4 version
<li>04/2002: 1.0.6 version
<li>07/2003: 1.0.10 version
<li>05/2005: 2.0.0 version
<li>12/2005: 2.0.2 version
<li>08/2006: 2.0.4 version
<li>09/2007: 2.2.0 version
<li>08/2008: 2.2.2 version
<li>04/2009: 2.2.4 version
<li>12/2009: 2.4.0 version
<li>11/2010: 2.4.2 version
<li>05/2011: 2.4.4 version
<li>01/2012: 2.6.0 version
<li>12/2012: 2.6.2 version
<li>02/2014: 2.6.4 version
</ul>
<li><a name='versions'></a>
<h3>Which versions exist, and which one should I use?</h3>
<p>The latest official version is 2.6.4, the second fixes release in the 2.6.x series.
New development is performed in 2.7.x series, which eventually
gets released as 2.8.0 or 3.0.0, depending on milestones achieved.
<h4>Historic versions</h4>
<p>FPC's version numbering changed a few times over the years. Pre 1.0 versioning
moved to the <a href="http://wiki.freepascal.org/1.0_versioning">Wiki 1.0 versioning article.</a>
<h4>Modern versioning</h4>
<p>Together with the release of 1.0 the version numbering was
slightly changed, and a system in versioning resembling the Linux
kernels has been introduced.
<p>
<ul>
<li>Releases that only fix bugs in version 1.0 are numbered 1.0.x.
<li>Post 1.0 development (the so called snapshots) have version number
1.1.x.
<li>Eventually the 1.1.x versions, when stabilized were released
as the 2.0.x series, preceded by betas marked as 1.9.x. Fixes on
2.0 release were numbered 2.0.x, fixes on 2.2 release 2.2.x, fixes on the 2.4 release as 2.4.x etc</li>
<li>The new development after the 2.4.0 release is numbered 2.5.x
and so on.
<li>Repackagings that affect sources are indicated with a single letter as
suffix (e.g. 2.0.4a), this is usually the case for platforms that weren't part of the original release round.
<li>The stable branch (fixes_2_4) always has an odd last number (2.4.1, 2.4.3).
Compilers with such versions are snapshots, and e.g. a snapshot with 2.4.1 can
be anywhere between 2.4.0 and the moment 2.4.2 branched off (may 2010). Likewise
the fixes_2_4 branch will hold version 2.4.3 till 2.4.4 is branched off (typically
two months before its release). After 2.4.4 the stable branch's number is updated to 2.4.5 etc.
</ul>
<p>
<p>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).
<p>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).
<p>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.
<p>Snapshots of the stable branch (fixes_2_6) 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.
<p>We advise all users to upgrade to the newest version for their
target (preferably the new stable 2.6.x series).
<p>A graphical timeline of the FPC project plus its near future would
be:
<img src="pic/timeline.png">
<li><a name='FPandGNUPascal'></a>
<h3>Free Pascal and GNU Pascal - a comparison</h3>
<DL>
<DT><b>Aim:</b>
<DD>Free Pascal tries to implement a Borland compatible pascal
compiler on as many platforms as possible. GNU Pascal tries to
implement a portable pascal compiler based on POSIX.
<DT><b>Version:</b>
<DD>Currently, Free Pascal is at version 2.6.4 (Februari 2014). GNU Pascal is at
version 2.1 (from 2002, which can be built with several different GCC's as backend;
their Mac OS X version is an exception though, as it follows the GCC version number).
<DT><b>Tracking:</b>
<DD>Between releases, development versions of FPC are available through daily snapshots
and the source via SVN. GPC issues a set of patches to the last version a few times
a year, and there are regular snapshot for OS X and Windows, made by users.
<DT><b>Operating systems:</b>
<DD>Free Pascal runs on a large amount of platforms of OSes,
e.g. DOS, Win32 (no Unix porting layer needed), Linux, FreeBSD,
NetBSD, OS/2, BeOS, Classic Mac OS, Mac OS X, and AmigaOS, on, at
the moment the following architectures: x86,
x86_64 (AMD64), Sparc, PowerPC, PowerPC64, ARM, Motorola m68k (m68k only in version 1.0.x
and the latest development versions) and MIPS (both big endian and little endian mode available
in the latest development versions).
GNU Pascal runs basically on any system that can run GNU C, and for which the buildprocess was verified.
<DT><b>Bootstrapping:</b>
<DD>FPC requires a suitable set of binutils (AS,AR,LD) on some platforms, gmake and a commandline compiler. New architectures/OSes are crosscompiled.
GPC bootstraps via a suitable version of GCC, and requires a full set of binutils, flex, bison, gmake, a POSIX shell and libtool
<DT><b>Sources:</b>
<DD>Free Pascal is entirely written in Pascal (about 6 MB of source
code), while GNU Pascal is written in C (it's an adaptation of the GNU
C compiler: 2.8 MB code + 8 MB of GNU C code)
<DT><b>Language:</b>
<DD>Free Pascal supports the Borland Pascal dialect,
implements the Delphi Object Pascal language and has some Mac Pascal extensions.
GNU Pascal supports ISO 7185, ISO 10206, (most of) Borland Pascal 7.0
<DT><b>Extensions:</b>
<DD>Free Pascal implements method, function and operator overloading (later Delphi versions add these, so strictly not an extension anymore)
GNU Pascal implements operator overloading.
<DT><b>License:</b>
<DD>Both compilers come under the GNU GPL.
<DT><b>Author:</b>
<DD>Free Pascal was started by Florian Klämpfl, Germany
(florian@freepascal.org), GNU Pascal was started by Jukka Virtanen,
Finland (jtv@hut.fi). </DD></DL><br>
<li><a name='general-license'></a>
<h3>License and copyright information</h3>
<p> 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.
<p>This extra exception to the LGPL is added:<br><I> 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.</I>
Please note that you still have to comply to the LGPL, which, for example,
requires you to provide the source code of the runtime library. If you want
to write proprietary closed source software, please do this to comply:
<ul>
<li>Most people can satisfy the source code requirement by mentioning
the rtl source code can be downloaded at the Free Pascal
web site: if you did not modify the rtl this is considered adequate to
satisfy the LGPL requirement of providing source code.
<li>If you made modifications to the runtime library, you cannot keep them
for yourself, you must make them available if requested.
<li>Distribute the LGPL license with your product.
</ul>
<p>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.
<li><a name='WhereToGetFP'></a>
<h3>Getting the compiler</h3>
<p>The latest official stable Free Pascal release is available for download
from all <a href="http://www.freepascal.org/download.var">official mirrors</a>
<li><a name='general-install'></a>
<h3>Free Pascal installation hints</h3>
<ul>
<li> Do not install the compiler in a directory which contains spaces
in its name, since some of the compiler tools do not like these
</ul>
<li><a name='ftpproblems'></a>
<h3>Why do i have to supply a user name and password to get Free Pascal ?</h3>
<p> 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.
<li><a name='general-connectftp'></a>
<h3>Access denied error when connecting to the Free Pascal FTP site</h3>
<p>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.
<li><a name='snapshot'></a>
<h3>I want a new version NOW</h3>
<p>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.
<p>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.
<p>The latest snapshot can always be downloaded from the <A
href="http://www.freepascal.org/develop.var#snapshot">development</a>
web page.
<li><a name='installsnap'></a>
<h3>Installing a snapshot</h3>
<p>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.
<p> 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" (InfoZIP unzip doesn't
require any special parameters). 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.
<li><a name='HOMEWORK'></a>
<h3>I have to write a program for homework. Can you help?</h3>
<p>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.
<li><a name="windowsapp"></a>
<h3>How do I make a real Windows application with windows and menu bars?</h3>
The easiest way is to <a href='http://www.lazarus.freepascal.org'>download Lazarus</a>.
It won't be just a Windows application, it will also work under Linux, FreeBSD and
Mac OS X.
<li><a name="game"></a>
<h3>How do I make a game with Free Pascal? Can I make a game like Doom 3?</h3>
Yes, you can make games with Free Pascal and if you are really good you can make
a game like Doom 3. Making games is difficult, you need to be an experienced
programmer to make them. The web site <a href='http://www.pascalgamedevelopment.com'>
www.pascalgamedevelopment.com</a> is a community of people who program games in Free
Pascal and Delphi.
<p>
If you want a start, please start to study <a href='http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME'>JEDI-SDL</a>
or <a href='http://ptcpas.sourceforge.net'>PTCPas</a>. Also you can try to study an existing game, for example
<a href='http://thesheepkiller.sourceforge.net'>The Sheep Killer</a> is a very simple game and it should not be
very hard to understand its code.
<li><a name='ErrorPos'></a>
<h3>Getting more information when an application crashes</h3>
<OL>
<li>The easiest possibility is to recompile your program with -gl
debugging option. This way unit LineInfo is automatically linked in,
and the printout after a program crash then contains source line
numbers in addition to addresses of the crash. To see runtime library (RTL)
functions in the backtrace with their real name, you have to recompile
the RTL with -gl too.
<li>For more comprehensive checking, compile the
program with debugging information (use the -g command line option)
<li>Load the program in the debugger <PRE>gdb(pas)(w) --directory=<src dirs> myprog.exe</PRE>Notes:
<ul>
<li>Under UNIX systems (Linux, the BSD's), don't add the ".exe" after myprog
<li>"<TT>src dirs</TT>" is a list of directories containing the
source code files of myprog and the units it uses seperated by
semi-colons (";"). The current directory is automatically included.
</ul>
<li>Once inside the debugger, you can (optionally) set the command
line options that will be passed to your program using the command
"<TT>set args <option1 option2 ...></TT>"
<li>To start the program, type "<TT>run</TT>" and press enter
<li>After the program has crashed, the address of the instruction
where the crash occurred will be shown. The debugger will try to
display the source code line corresponding with this address. Note
that this can be inside a procedure of the RTL, so the source may not
always be available and most likely the RTL wasn't compiled with
debugging information.
<li>If you then type "<TT>bt</TT>" (BackTrace), the addreses in the
call stack will be shown (the addresses of the procedures which were
called before the program got to the current address). You can see
which source code lines these present using the command
<PRE>info line *<address></PRE>For example:<PRE>info line *0x05bd8</PRE>
</OL>
<li><a name='general-heap'></a>
<h3>Increasing the heap size</h3>
<p>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.
<p>You can specify the size of the heap with -Chxxxx.
<p>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.
<p>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.
<li><a name='general-doesntfindfiles'></a>
<h3>Compiler seems to skip files in directories that -Fu points to</h3>
<p>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 <TT>touch</TT>
will solve it.
<p>
Also note that FPC, contrary to Turbo Pascal keeps track of includefiles. Modified
includefiles or duplicate names might trigger an attempt at recompiling
<li><a name='binariesbig'></a>
<h3>Why are the generated binaries so big?</h3>
There are several reasons and remedies for this:
<OL>
<li>
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.
<li>Normally, all symbol information is included in the resulting
program (for easier debugging). You can remove this by using the -Xs
command line option when compiling your program (it won't do anything
when compiling units)
<li>You can use UPX to pack the .EXEs (just like e.g. pklite) for Dos
(GO32v2) and Windows targets. Look <A
href="http://upx.sourceforge.net/">here</a> for
more info.
<li>You can use LXLITE for packing EMX binaries, but you won't be able
to run them under DOS (with extender) any more then. This issue is
not relevant for native OS/2 binaries compiled for target OS2 with
version 1.9.x and above, because these don't run under DOS anyway.
In addition, it might not be possible to use compressed binaries
on lower OS/2 versions (like 2.x) depending on chosen type of
compression. LXLITE can be found e.g. on
<a href="http://hobbes.nmsu.edu/">Hobbes</a>, search for LXLITE.
<li>Turn on optimalisations, both for supplied packages (RTL, FV, FCL)
and for your own code, this will also decrease the code size.
<li>Keep in mind that under Windows NT/2k/XP/Vista, compressed binaries startup
relatively slow. Test under various conditions (OS, CPU speed, memory)
if the behaviour is acceptable before compressing
</OL>
Generally Free Pascal generates smaller binaries than modern competing compilers,
however, it doesn't hide code in large dynamic libraries. Free Pascal generates
larger binaries than compilers from long ago do. Large framework libraries result
in larger executables.
See also the <a href="http://wiki.freepascal.org/Size_Matters">Size Matters wiki entry</a>.
<li><a name=cfgfiles></a>
<h3>Configuration file problems (fpc.cfg or ppc386.cfg)</h3>
<p> Starting from version 1.0.6 of Free Pascal, the configuration
file is called <TT>fpc.cfg</TT> instead of <TT>ppc386.cfg</TT>.
For backward compatibility , <TT>ppc386.cfg</TT> is still searched first
and, if found, is used instead of <TT>fpc.cfg</TT>.
<p> Since 1.0.6 is now over 5 years old,
the <TT>ppc386.cfg</TT> support will be phased out. 2.2.2 will warn, and 2.4.0+ will no longer search <TT>ppc386.cfg</TT>
<p> Versions prior to Free Pascal 1.0.6 do not recognize <TT>fpc.cfg</TT>,
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 <TT>ppc386.cfg</TT>.
<li><a name='runerror'></a>
<h3>Runtime errors</h3>
<p> 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 :
<PRE>
Runtime error 201 at $00010F86
$00010F86 main, line 7 of testr.pas
$0000206D
</PRE>
<p> 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.
<li><a name='stdunits'></a>
<h3>Standard units</h3>
<p> 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.
<!--
<li><a name=internaldocs></a>
<h3>How does the compiler work internally?</h3>
<p>A draft document describing the internals of the Free Pascal compiler is
available <a href="ftp://ftp.freepascal.org/pub/fpc/docs/fpc-int10.zip">here</a>.
-->
<li><a name=debugsmart></a>
<h3>Debugging smartlinked code does not fully work</h3>
<p>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.
<p> While debugging, it is not recommended to use the
smartlinking option.
<li><a name=debugshared></a>
<h3>Debugging shared library (dynamic linked library) code does not fully work</h3>
<p>Debugging shared libraries (or dynamic linked libraries) produced
by the Free Pascal compiler is not officially supported.
<li><a name='cantfindunit'></a>
<h3>PPU files binary compatibility between versions</h3>
<h3>Can't compile a program using a binary only version of a unit</h3>
<p>
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.
<p>
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.
<p>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.
<p>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.
<li><a name='isoxpascal'></a>
<h3>Will you support ISO Extended Pascal?</h3>
FPC's primary goal is to be a Turbo Pascal and Delphi-compatible compiler, and it also
supports a subset of the Mac-Pascal dialect. All of these are incompatible to some extent
with the ISO Standard and Extended Pascal languages. While in theory it would be possible
to add a separate ISO Standard or Extended Pascal mode, until now no people interested in
such functionality have stepped up to work on such features.
<p>
<a href="http://www.gnu-pascal.de/">GNU-Pascal</a> 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.
<li><a name='dotnet'></a>
<h3>What about .NET?</h3>
Occasionally, users ask about a FPC that supports .NET, or our
plans in that direction. <p>
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 won't be possible
in the future.<p>
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:
<OL>
<li>
Pascal is a language that uses pointers, and existing codebases
can only be unmanaged. Unmanaged code is not portable under .NET,
so that already kills most possible benefits. This also means that
existing FPC and Delphi code won't run on .NET. There are more
such little language problems.</li>
<li>FPC's libraries don't base on .NET classes and datamodels (and
can't be changed to do so without effectively rewriting them),
moreover the libraries could only be unmanaged too, or they
would be incompatible</li>
<li>There is nothing <em>practical</em> known yet about how portable
an average .NET program will be. Little experiments with hello
world level code mean nothing, that kind of code works with
nearly any language. A good test would be to see existing non trivial
codebases run unmodified under mono, that were not designed with mono
in mind. Just like we try to do for
Delphi</li>
<li> The fact that on Windows 80% of the .NET code seems to be
ASP.NET doesn't help either. This makes porting existing code
less useful (since ASP.NET is tied to IIS), and new codebases of
portable code can be set in nearly every language </li>
<li>Operating System dependant code wouldn't work anymore, since
the win32 interface is unmanaged.
</OL> <p>
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.
This is not adding support for .NET in FPC, but reimplementing FPC
on .NET from near scratch without backwards compatibility. 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.<p>
While unmanaged code has some uses (allows to integrate with managed
code inside windows easier), this still needs a codegenerator
backend to be written, interfaces and libraries defined, for little
practical use. This means a <b>lot of work</b> and since .NET take
up is not really high, this might not be worth it, since an
unmanaged FPC/.NET would only be minimally used. <p>
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.<p>
Since support for <a href="http://wiki.freepascal.org/FPC_JVM">generating JVM bytecode</a> 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.<p>
</OL>
<li><h2>Pascal language related information</h2>
<OL>
<li><a name='PortingCPU'></a>
<h3>Considerations in porting to other processors</h3>
<p>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.
<ul>
<li>Limit your use of asm statements unless it is time critical code
<li>Try not to rely on the endian of the specific machines when doing
arithmetic operations. Furthermore, reading and writing of binary data
to/from files will probably require byte swaps across different endian
machines (swap is your friend in this case). This is even more
important if you write binary data to files. Freepascal defines
<CODE>ENDIAN_LITTLE</CODE> or <CODE>ENDIAN_BIG</CODE> to indicate the
target endian.
<li>Try limiting your local variables in subroutines to 32K, as this
is the limit of some processors, use dynamic allocation instead.
<li>Try limiting the size of parameters passed to subroutines to 32K,
as this is the limit of some processors, use const or var parameters
instead.
<li>The <TT>CPU32</TT> or <TT>CPU64</TT> (defined by FPC starting
from version 1.9.3) are defined indicating if the target is a 32-bit or
64-bit cpu; This can help you separate 32-bit and 64-bit specific code.
<li>Use the <TT>ptruint</TT> type (defined by FPC starting
from version 1.9.3) when declaring an ordinal that will store
a pointer, since pointers can be either 32-bit or 64-bit depending on
the processor and operating system.
</ul>
<p>
<li><a name='PortingOS'></a>
<h3>Considerations in porting code to other operating systems</h3>
<p>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.
<ul>
<li>File sharing is implemented differently on different operating
systems, so opening already opened files may fail on some operating
systems (such as Windows). The only correct way to make sure to
have the same file sharing behavior is to use the I/O routines
furnished in <TT>sysutils</TT>.
<li>Clean up at the end of your program, i.e. close all files on exit, and
release all allocated heap memory, as some operating systems don't like it
when some things are left allocated or opened.
<li> Some operating systems limit the local stack space which can be allocated,
therefore it is important to limit subroutine nesting, and the amount of
local variables. Limiting total stack space usage at a given moment to
at most 256 KBytes while make porting easier.
<li> Do not hard code paths to files, try to use relative paths
instead
<li> Use the following constants (defined in the system unit)
to get information on files, line endings, and to build paths:
<ul>
<li> <TT>LineEnding</TT> : Indicates the characters which end a text line
<li> <TT>LFNSupport</TT> : Indicates if long filenames are supported (more then 8.3 characters)
<li> <TT>DirectorySeparator</TT> : The character or characters which separate path components
<li> <TT>DriveSeparator</TT> : The character which separate the drive specification from the rest
of the path
<li> <TT>PathSeparator</TT> : The character which separates directories in the search path environment
<li> <TT>FileNameCaseSensitive</TT> : Boolean indicating if the filenames for this system are case-sensitive or not
<li> <TT>AllFilesMask</TT> : String containing a wildcard expression for all files
</ul>
It is also possible to use the <TT>PathDelim</TT>, <TT>PathSep</TT> and <TT>DriveDelim</TT> constants
defined in <TT>sysutils</TT>.
</ul>
<p>
<li><a name='OOP'></a>
<h3>Compiling Delphi code using Free Pascal</h3>
<p>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 incompatibilities also check the manual.
<li><a name='HowcanIbuildaunit'></a>
<h3>Building a unit</h3>
<p>It works like in Turbo Pascal. The first keyword in the file must be
UNIT (not case sensitive). The compiler will generate two files:
<TT>XXX.PPU</TT> and <TT>XXX.O</TT>. 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.
<li><a name='CompileSystemUnit'></a>
<h3>Compiling the system unit</h3>
<p>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.
<p>It is possible to do all this manually, but you need more detailed
knowledge of the RTL tree structure for that.
<li><a name='Howdoesprocedureoverloadingwork'></a>
<h3>How does procedure overloading work?</h3>
<p>Here is a procedure overloading example:
<PRE>
procedure a(i : integer);
begin
end;
procedure a(s : string);
begin
end;
begin
a('asdfdasf');
a(1234);
end.
</PRE>
<p>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.
<li><a name='HowToCallCFuncuntions'></a>
<h3>Calling C functions</h3>
<p>
It is possible to call functions coded in C, which were compiled
with the GNU C compiler (<TT>GCC</TT>). For calling the
C function strcmp declare the following:
<PRE>function strcmp(s1 : pchar;s2 : pchar) : integer;cdecl;external;</PRE>
<li><a name='IntegratedAssemblerSyntax'></a>
<h3>Integrated Assembler syntax</h3>
<p>The default assembler syntax (AT&T style) is different from the
one in Borland Pascal (Intel style).
<p>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.
<p>Since version 1.9.2, the compiler also uses the register calling
convention, which means the compiler can assemble assembler routines
in Delphi source code without modification.
<p>Since version 1.9.8, the register calling convention is default
for Delphi mode.
<p>A description of the AT&T syntax can be found in the GNU
Assembler documentation.
<li><a name='systemnotfound'></a>
<h3>Unit system not found errors</h3>
<p>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.
<p>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.
<p>If the compiler can't find this unit there are three possible causes:
<OL>
<li>The ppc386.cfg or fpc.cfg isn't in the same path as the compiler
executable (go32v2, win32 and OS/2) or can't be found as
"/etc/fpc.cfg" or ".fpc.cfg" in your homedirectory (Linux).
<li>The fpc.cfg or ppc386.cfg doesn't contain the -Fu line, or a wrong one.
See the <a href="http://www.stack.nl/~marcov/buildfaq.pdf">build faq (PDF)</a>, especially the chapters
about the fpc.cfg and the directory structure.
<li>The files ARE found but the wrong version or platform. Correct
ppc386.cfg or fpc.cfg to point to the right versions or reinstall the right
versions (this can happen if you try to use a <A
href="#snapshot">snapshot</a>
compiler while the -Fu statement in the used fpc.cfg still points to
the RTL that came with the official release compiler).
</OL>
<p>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:
<p>
<PRE>
Dos, OS/2, Windows: ppc386 programname -vt |more<br>
unix, linux: ppc386 programname -vt |less<br>
</PRE>
<p>
<li><a name='extensionselect'></a>
<h3>There is a new extension that will be really useful. Will you include it?</h3>
Occasionally somebody asks for a new extension on the maillist,
and the discussions that follow have a recurring pattern. An
extension is quite a big deal for the FPC team, and there are
some criteria that are used to select if an extension is
"worth" the trouble. The most important pre-selection criteria are:
<OL>
<li>Compatibility must not be compromised in any way. Existing
codebases on at least the Pascal level must keep
running. This is often more difficult than most people
think.
<li>The extension must have real value. Anything that is only
a shorter notation does not apply, unless it is
out of compatibility with an existing Pascal/Delphi
codebase. Practically it means it must make something
possible that can't be done otherwise or be a compatibility
item
<li>The change must fit in with the scope of the project,
implementing a Pascal compiler which can have a RAD
and generic DB system. This excludes features like
inline SQL, and large garbage collected objectframeworks.
</OL>
Exceptions to the second rule are sometimes made for platform
specific reasons (e.g. interfacing to some other language or
OS). The first rule is often a problem, because issues aren't
easily recognizable unless one has tried to make extensions
before. Best is to make a thoroughly written proposal that the
devels can review with
<ul><li> Explanation of the feature
<li> Why it is needed, what does it make possible?
<li> How you would implement it?
<li> Lots of examples of typical use, and tests for possible problem
cases
</ul>
Try to be verbose and really try to view this from the viewpoint
of somebody who has to implement it, and try to make examples
that span multiple units and procedures, and review what happens.
Be critical, try to punch holes in your
own reasoning and find possible problematic cases, and document
them.
<p>
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 devels are volunteers with to-do lists that are
booked till the next decade. You can't simply expect they'll
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, and submit patches,
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.
</OL>
<li><h2>Runtime library related information</h2>
<OL>
<li><a name='HowToUseGraph'></a>
<h3>Using the graph unit with Free Pascal</h3>
<p>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.
<li><a name=WrongColors></a>
<h3>Why do I get wrong colours when using the graph unit?</h3>
<p>If you use <TT>detect</TT> 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.
<p>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):
<ul>
<li>15 bit color: lower 5 bits are blue intensity, next come 5 bits of
green and then 5 bits of red. The highest bit of the word is ignored.
<li>16 bit color: lower 5 bits are blue intensite, next come *6* bits
of green and then 5 bits of red.
</ul>
<p>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
<TT>D8BIT</TT> as graphdriver and <TT>DetectMode</TT> 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 <TT>GrNotDetected</TT> after you called InitGraph and you can
retry with graphdriver <TT>D4BIT</TT>. 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.
<li><a name='fileshare'></a>
<h3>File sharing and file locks</h3>
<p> The standard runtime library file I/O routines open
files in the default sharing mode of the operating system
(<TT>system, objects</TT> units). Because of this, you
might get problems if the file is opened more than once either
by another process or the same process.
<p> Generally the behaviors for the different operating
systems are as follows :
<ul>
<li> UNIX systems : There is no verification at all.
<li> Windows : An access denied error will be reported.
<li> Amiga : An access denied error will be reported.
<li> DOS / OS/2 : If the file is opened more than once by
the same process, no errors will occur, otherwise an
access denied error will be reported.
</ul>
<p>There are two ways to solve this problem:
<ul>
<li> Use specific operating system calls (such as file locking
on UNIX and Amiga systems) to get the correct behavior.
<li> Use the <TT>sysutils</TT> unit or the Free Component Library
<TT>TFileStream</TT> File I/O routines, which try
to simulate, as much as possible, file sharing mechanisms.
</ul>
<li><a name='filemode'></a>
<h3>File denied errors when opening files with reset</h3>
<p> Trying to open files using <CODE>reset</CODE> on non-text files
might cause a Runtime Error 5 (Access denied).
<p> All files opened using the above system unit routine use the current
<CODE>filemode</CODE> value to determine how the file is opened. By
default, <CODE>filemode</CODE> is set to 2 (Read/Write access).
<p>So, a call to <CODE>reset</CODE> on non-text files does <EM>not</EM>
indicate that the file will be opened read-only. So, trying to open a file
using <CODE>reset</CODE> with the defaults will fail on read-only files.
<CODE>filemode</CODE> should be set to 0 (Real-only access) before
calling <CODE>reset</CODE> to solve this problem. A sample solution
is shown below.
<PRE>
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.
</PRE>
<p> For more information, consult the Free Pascal reference manual
</OL>
<LI><h2>DOS related information</h2>
<OL>
<li><a name=dos-release></a>
<h3>Releasing software generated by the DOS compiler</h3>
<ul>
<li> If your program uses floating point code (which is
very probable), make sure to read "<a href="#fp386">Applications created
with Free Pascal crash on 80386 systems</a>" regarding special issues
which might occur. Math coprocessor emulation software is then
required (<TT>wmemu387.dxe</TT> should be redistributed with your software)
<li> The target system must have a DPMI server. To avoid problems,
the file <TT>cwsdpmi.exe</TT> should always be redistributed with your
application
<li> The target system must have DOS 3.3 or later
<li> The default heap size is 2 Megabytes. Automatic growing of the heap is supported
<li> The default stack size is 256 Kbytes. See also "<a href="#dos-stack">Changing
the default stack size</a>"
<li> The stack checking option is available on this platform.
</ul>
<p>
<li><a name=dos-debugging></a>
<h3>Debugging</h3>
<p>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.
<p>
<li><a name=dos-dll></a>
<h3>Dynamic Libraries</h3>
<p>Creation or use of shared libraries (also called dynamic link libraries) is not
supported under this platform.
<li><a name=dos-profile></a>
<h3>Profiling</h3>
<p>Profiling with <TT>gprof</TT> is supported for this platform.
<li><a name=FPwithoutfpu></a>
<h3>Running Free Pascal without a math coprocessor?</h3>
<p>On the Intel version the emulator is automatically loaded by the
compiler if you add the following commands to your autoexec.bat:
<p><PRE>
SET 387=N
SET EMU387=C:\PP\BIN\GO32V2\WEMU387.DXE
</PRE>(don't forget to replace the <TT>C:\PP</TT> with the directory
where you installed FPC)
<li><a name=fp386></a>
<h3>Applications created with Free Pascal crash on 80386 systems</h3>
<ul>
<li>
<p>Trying to run an application which does floating point operations
on a 386 system without a math co-processor will crash unless
the <TT>emu387</TT> unit is used, as this unit loads the math co-processor
emulator (called <TT>wmemu387.dxe</TT>). You can add the unit as follows:
<p><PRE>
program myprog;
uses emu387, ...
</PRE>
<p>When the application is released, the software package should also
include the wmemu387.dxe redistributable file to avoid problems. .
<li>
<p>Some 80386 systems have a hardware bug which corrupt the accumulator
register <TT>EAX</TT> if it is used in a <TT>MOV</TT> instruction just
after a <TT>POPAL</TT> 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
</ul>
<p>
<li><a name=nomousegraph></a>
<h3>The mouse cursor is not visible in graphics screens</h3>
<p>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 <A
href="ftp://ftp.logitech.com/pub/techsupport/mouse/m643 w31.exe">here</a>
<li><a name=accessioports></a>
<h3>Accessing I/O ports</h3>
<p>With versions before 0.99.10: if you're under DOS you can use the
<TT>outport*</TT> and <TT>inport*</TT> procedures of the go32 unit.
<p>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).
<p>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)
<li><a name=HowToAccessDosMemory></a>
<h3>Accessing DOS memory / Doing graphics programming</h3>
<p>You can do like in Turbo Pascal, via absolute or mem[]. For larger memory
blocks use the dosmemput/dosmemget routines in the <TT>Go32</TT> unit.
<li><a name=dos-stack></a>
<h3>Changing the default stack size</h3>
<p>Under the DOS (GO32V2) target, the default stack size to 256 bKbytes. This can
be modified with a special DJGPP utility called <TT>stubedit</TT>. 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.
<p>
<li><a name=dos-os2></a>
<h3>Using OS/2 generated applications under DOS</h3>
<p>OS/2 applications (including the compiler) created with version 1.0.x
and before should work correctly under vanilla DOS, since they are 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 (<TT>emx.exe</TT>) to execute properly. It may be
necessary to distribute these files with the generated application.
<p>Binaries created for target OS2 with version 1.9.x and above cannot
run under DOS any more, because they directly use OS/2 API functions not
available when running under extender - you need to compile for a newly added
EMX target which provides this capability of running on both platforms.
</OL>
<LI><h2>Windows related information</h2>
<OL>
<li><a name=win-release></a>
<h3>Releasing software generated by the windows compiler</h3>
<p> 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:
<ul>
<li> The default heap size is 256 Kbytes. Automatic growing
of the heap is supported. It is to note that Windows 95,
Windows 98 and Windows Me limit the heap to 256 Mbytes
(this is a limitation of those Operating systems, not of Free Pascal,
consult MSDN article Q198959 for more information).
<li> Stack size is unlimited
<li> The stack checking option is not available on this platform.
</ul>
<p>
<li><a name=win-debugging></a>
<h3>Debugging</h3>
<p>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 windows targets.
<p>
<li><a name=win-dll></a>
<h3>Dynamic libraries</h3>
<p>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.
<li><a name=win-profile></a>
<h3>Profiling</h3>
<p>Profiling is supported using <TT>gprof</TT>, starting with version 1.0.7.
It requires mingw to be installed, and that <TT>fpc.cfg</TT> point to the
correct library paths.
<li><a name=win-graph></a>
<h3>Graph and problems with keyboard, mouse and "dummy dos windows"</h3>
<p>Problem:
<ul>
<li>If you use the Graph unit under Win32, you can't use the API mouse
unit for mouse support or use the win32 Crt unit to get keyboard data.
The reason for this is that the window popped up is a GUI window, and
not a console one.
</ul>
Solution:
<ul>
<li>Use units WinMouse and WinCrt instead.
</ul>
<p>
<p>Problem:
<ul>
<li>When you follow the above advice, and you run your purely Graph
based win32 program from the RUN menu in windows, a dummy dos window
is opened.
</ul>
Solution:
<ul>
<li>Set the application type to GUI: <PRE>{$apptype GUI}</PRE>
and put this line before your programs InitGraph statement:
<PRE>ShowWindow(GetActiveWindow,0);
</PRE>This will hide the dos window window.
</ul>
<p>
<p>Some of the demos (like fpctris) use these techniques
<li><a name=win-cygwin></a>
<h3>Cygwin binary directory in your path sometimes causes strange problems</h3>
<p>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.
<p>Solution: don't put cygwin in your global path for now, only
add it when needed. Efforts are made to work around this.
<p>Possible untested workaround: add mingw sh.exe to a directory before
the cygwin binary directory in the path
<li><a name=win95-fpc></a>
<h3>Using the DOS compiler under Windows 95</h3>
<p>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).
<li><a name=win-os2></a>
<h3>Using OS/2 generated applications under Windows</h3>
<p>Normally OS/2 applications (including the compiler) created with version 1.0.x
and before should work under Windows, since they are based on EMX - see
<a href="#dos-os2">note about running OS/2 applications under DOS</a> for
more detailed information. 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.
<li><a name=win-dos></a>
<h3>Using DOS generated applications under windows</h3>
<p>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.
<li><a name=win-ide-mouse></a>
<h3>The mouse cursor does not respond in the Windows IDE</h3>
<p>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.
</OL>
<LI><h2>UNIX related information </h2>
<p>This section also applies to most unix variants, such as
linux, freebsd and netbsd.
<OL>
<li><a name=unix-release></a>
<h3>Releasing software generated by the unix compilers</h3>
<ul>
<li> The default heap size is 256 Kbytes for the intel version,
and 128 Kb for the m68k versions. Automatic growing of the
heap is supported.
<li> There is no stack space usage limit.
<li> Under Solaris and QNX, stack checking is simulated.
<li> Minimal operating system versions :
<ul>
<li> Linux : Kernel v2.4.x or later.
<li> FreeBSD : version 5.x or later. (4.x can be made to work with minor work)
<li> NetBSD : version 1.5 or later.
<li> Solaris : version 5.7 of SunOS or later
(should work with earlier versions, but untested).
<li> Qnx : version 6.1.0 or later
(should work with earlier versions, but untested).
<li> Mac OS X : version 10.3.9 or later
</ul>
</ul>
<p>
<li><a name=unix-debugging></a>
<h3>Debugging</h3>
<p>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) SVN snapshot is
recommended for Pascal support and ease of building
<p>
<li><a name=unix-dll></a>
<h3> Dynamic libraries </h3>
<p>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.
<p>
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.
<p>
Importing code from shared libraries does work as expected though, since
it does not require usage of position independant code.
<li><a name=unix-profile></a>
<h3>Profiling</h3>
<p>Profiling is supported using <TT>gprof</TT> 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.
<li><a name=libci386></a>
<h3>Libc is missing on platforms other than Linux/i386</h3>
<P>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.
<P>To access Unix functionality, please use units like baseunix
and unix.
<li><a name=vgamissing></a>
<h3>Why can't the linker find "vga"?</h3>
<p>This error typically looks like this:<PRE>
Free Pascal Compiler version 2.2.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
</PRE>
<p>
<p>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
<li><a name=unix-asldmissing></a>
<h3>Compiler indicates missing as and ld</h3>
<p> Normally unix systems have the assembler (<TT>as</TT>) and linker
(<TT>ld</TT>) pre-installed and already in the search path. That is
the reason why these tools are not supplied with the compiler.
<p>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.
<p> It is to note that the Solaris version of FPC contains these tools.
<li><a name=unix-ld219></a>
<h3>An error occurred while linking, or "did you forget -T?"</h3>
<p>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.</p>
<p>At the same time, LD has been modified to emit a warning of the form
<pre>
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
</pre></p>
<p>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.</p>
</OL>
<LI><h2>OS/2 related information </h2>
<OL>
<li><a name=os2-release></a>
<h3>Releasing software generated by the OS/2 compiler</h3>
<p> 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:
<ul>
<li> All applications generated for the OS/2 (EMX) target require
the EMX 0.9d (or later) runtime files to run. These files
should be redistributed with your software. All the files
which should be redistributed are included in <TT>emxrt.zip</TT>
<li> Under OS/2, <TT>LIBPATH</TT> should be modified to add the EMX
DLL paths. Otherwise, programs will not run and will abort
with an error 'Cannot find EMX.dll'.
<li> The default heap size is 256 Kbytes.
Automatic growing of the heap is supported.
<li> Stack can grow up to 256 Kbytes by default. This can be changed by
the user or developper using the <TT>emxstack</TT> or <TT>emxbind</TT>
utilities.
</ul>
<p>
<li><a name=os2-debugging></a>
<h3>Debugging</h3>
<p>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.
<p>
<li><a name=os2-dll></a>
<h3> Dynamic libraries </h3>
<p>
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).
<li><a name=os2-profile></a>
<h3>Profiling</h3>
<p>Profiling is currently not supported for this platform.
<li><a name=os2-dos></a>
<h3>Using DOS generated applications under OS/2</h3>
<p>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.
<p>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.
<li><a name="instal106os2"></a><h3>INSTALL.EXE of version 1.0.6 or below fails with an unknown error (-1) under OS/2</h3>
<p>
or
<h3>INSTALL.EXE of version 1.0.6 or above complains about missing TZ variable under OS/2</h3>
<p>
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
<a href="http://hobbes.nmsu.edu/pub/os2/apps/internet/time/time868f.zip">TIME868</a>
package.
<li><a name="os2-fp"></a><h3>OS/2 compiler not working after upgrading to 1.9.6 or newer</h3>
<p>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. <a href="http://www.warpupdates.mynetcologne.de/english/basesystem.html">WarpUpdates site</a>
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.
<li><a name="os2-as-failing"></a><h3>Compilation under OS/2 fails with error "Can't call the assembler"</h3>
<p>Apart from the point mentioned <a href="#os2-fp">above</a>,
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.
</OL>
<LI><h2>BeOS related information </h2>
<b>The BeOS port is current no longer maintained</b>
<OL>
<li><a name=beos-release></a>
<h3>Releasing software generated by the BeOS compiler</h3>
<p> Software generated for the BeOS target will only work
on the intel based version of BeOS.
<ul>
<li> The target system must have at least BeOS v4.0 or later
(BeOS 5.1d 'Dano' is <em>not</em> supported)
<li> The default heap size is 256 Kbytes.
Automatic growing of the heap is supported
<li> Stack size is set to 256 Kbytes. This cannot be changed
</ul>
<p>
<li><a name=beos-debugging></a>
<h3>Debugging</h3>
<p>
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
<p>
<li><a name=beos-dll></a>
<h3> Dynamic libraries </h3>
<p>
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).
<li><a name=beos-profile></a>
<h3>Profiling</h3>
<p>Profiling is currently not supported for this platform.
<li><a name=beos-linking></a>
<h3>BeOS Linking problems</h3>
<p>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
<a href="http://open-beos.sourceforge.net/dev.php">site.</a>
<p>
</OL>
<LI><h2>Amiga related information </h2>
<OL>
<li><a name=amiga-release></a>
<h3>Releasing software generated by the Amiga compiler</h3>
<ul>
<li> The target system must have AmigaOS v2.04 or higher
<li> The default heap size is 128 Kbytes.
Automatic growing of the heap is supported.
<li> Stack size is not set by the compiler, but by the <TT>stack</TT>
command on the CLI. Because of this, and because default
stack sizes for this target are small, it is recommended
to always compile software with stack checking enabled.
<li> By default, the compiler generates code for the 68020+
processor. The code generated will not work on 68000
and 68010 systems unless the <TT>-O0</TT> compiler switch
is used, and there is no runtime checking. It is up
to you to implement CPU verification at program startup. The
standard runtime libraries have been compiled for the
68000 target, and should not cause any problems.
<li> All floating point operations are simulated,
and use the <TT>single</TT> floating point type.
You will need to recompile all standard runtime
libraries and your application, with the software floating point
option off, if you wish to use hardware floating point.
</ul>
<p>
<li><a name=amiga-debugging></a>
<h3>Debugging</h3>
<p> Source level debugging is not supported for the Amiga target. Assembler
target debugging is possible though, using the excellent <TT>Barfly</TT>
debugger.
<p>
<li><a name=amiga-dll></a>
<h3> Dynamic libraries </h3>
<p>
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.
<li><a name=amiga-profile></a>
<h3>Profiling</h3>
<p>Profiling is currently not supported for this platform.
</OL>
<LI><h2>PalmOS related information </h2>
<OL>
<li><a name=palmos-release></a>
<h3>Releasing software generated by the PalmOS compiler</h3>
<ul>
</ul>
<p>
<li><a name=palmos-debugging></a>
<h3>Debugging</h3>
<li><a name=palmos-dll></a>
<h3> Dynamic libraries </h3>
<p>
<p>
</OL>
</OL>
</body></html>
|