Source code
I have tested build with gcc-3.4.6, gcc-4.1.2, gcc-4.2.4 and gcc-4.3.5. Before build copy or symlink the p subdirectry of gpc into gcc-x.y.z/gcc subdirectory of gcc tree (that is you should have directory called gcc-x.y.z/gcc/p). To build with gcc-3.4.6 (or earlier) apply backend patch. That is in gcc-3.4.6/gcc do Next, create build directory. In the build directory configure inculuding Pascal in list of languages to build like Note: GPC does not support multilibs, the '--disable-multilib' provents build failure due to this. To build with gcc-4.y copy the libgpc subdirectory into toplevel gcc directory (that is into gcc-4.y.z) and apply the backend patch from toplevel directory (that is inside gcc-4.x.y directory) using command: Then configure and build. Using gcc-4.3.5 you need to give 'configure' the '--disable-mapped-location' argument. On newer Debian systems (and possibly other Linux distributions) there is changed layout of include files and library files: several include files are in platform specific subdirectories like '/usr/include/x86 64-linux-gnu' and its subdirectories. Similarly libraries are in '/usr/lib/x86 64-linux-gnu'. Unpached gcc-3.4.6 can not find system include files and as result build fails. If problem with include files is worked around, then gcc-3.4.6 can not find essential library files and again build will files. To work around both problems do the following in the toplvel gcc-3.4.6 directory: Note: Do the above if you build native compiler and your Linux uses layout as above. System using old layout do not need this patch. In particular cross compilers seem to continue with old layout. In recent Linux systems declaration of 'ucontext' changed in incompatible way. If your system uses new declaration then you need to apply extra patch in toplevel gcc-3.4.6 directory: After applying the two patches (if needed) proceed as on older systems. If you apply the 'multilib-3.4.diff' patch on platform that do not need it, it may cause build failure. If you apply 'ucontext.diff' on platform that do not need it, you almost surely will get build failure. So, you need to find out features of you system and apply only relevant patches. Idealy this would be automated, but ATM this must be done by hand. 1) with gcc-4.y.z testsuite will fail if run immediately after build. Either install before running testsuite or copy 'libgpc.a' from libgpc build directory to gcc subdirectory and copy rts-confing.inc from libgpc build directory to gcc/p/rts subdirectory (you need to create rts subdirectiry) 2) I did not try to build shared libgpc -- it is probably broken. You would need to fix Makefiles to build it. 3) -Wparenthesis does not work with gcc-4.3.z 4) Utilities (binobj and gpidump) are not build with gcc-4.y.z
Excerpt from the source-code README · 3,408 chars · not written by Vinony
Wikidata facts
- Official website
- www.gnu-pascal.de
Show 1 more fact
- source code repository URL
- github.com/hebisch/gpc
Sources (2)
via Wikidata · CC0
Article · 日本語
GNU Pascal は、GNU Compiler Collection (GCC) のフロントエンドで構成されたPascalコンパイラで、Fortranや他の言語が GCC に追加された方法と同様である。GNU Pascalは、ISO 7185と互換性があり、ISO 10206 拡張Pascalの「ほとんど」を実装している。 GNU Pascalは GCCを利用する形をとっているため、GCCが利用可能なプラットフォームには即座に移植できる利点がある。ただし、GPCはフロントエンドであるため、GCCに大幅な変更が加えられた場合(メジャーな新しいバージョンなど)には適応する必要がある。通常、新しいメジャーバージョンはゆっくりと採用される (まだ大部分が3.xで、4.xの実験的なビルドがある)。これがおそらく、開発者がCターゲットのバックエンドを検討している理由の一つである。 2010年7月、ある開発者がGNU Pascalの将来について、開発者不足とGCC移植版としてのメンテナンスの問題をとりあげて公開質問をした。メーリングリスト上では活発な議論が行われ、開発者がCコード生成バックエンドとC++で実装し直す方向に傾くように見えた。メーリングリストは再び休止状態に鳴り、2016年12月の時点で、プロジェクトの今後の方向性についての発表やリリースは行われていない。 Dev-Pascal(英語版)は、GNU PascalをサポートするグラフィカルなIDEである。
Abstract from DBpedia / Wikipedia · CC BY-SA