Bootstrapping

[funlw65]

Is there a tutorial for bootstrapping  freepascal for a certain operating system?

[marcov]

Write a RTL for the new target and crosscompile basically.

Some of the tips and tricks are described in the buildfaq on the docs page.

[Thaddy]

What Marco writes is true, but an abstraction. Maybe you have a certain OS in mind?
For an experienced - with some compiler knowledge - programmer it is not that difficult, apart from work. I only struggle every time with startup code, but that might be me...., in fact I am sure its me... but eventually it succeeds.

[MarkMLl]

Maybe you have a certain OS in mind?

Unless it really is top-secret stuff I think we could usefully know, since there might be somebody aware of some obscure project (languishing in a corner of the wiki), or who has considered putting time into some target based on experience with another language or development environment.

MarkMLl

[funlw65]

Bootstrapping should be a common knowledge for the one that bases his entire cross-platform work on pascal (and especially on a specific version of freepascal). A pascal compiler that can't be compiled with the C compiler (freepascal killed gnu pascal).

[Thaddy]

Bootstrapping should be a common knowledge for the one that bases his entire cross-platform work on pascal (and especially on a specific version of freepascal). A pascal compiler that can't be compiled with the C compiler (freepascal killed gnu pascal).

Can you explain relevance? Freepascal is, just like some but not all C compilers, a self-compiling compiler. I am a bit bemused that you draw in C.
(GNU Pascal is not a very good example, since it is a compiler that can not compile itself and relies on C, hence it got dumped...)

[marcov]

Bootstrapping should be a common knowledge for the one that bases his entire cross-platform work on pascal (and especially on a specific version of freepascal).

Because?

A pascal compiler that can't be compiled with the C compiler (freepascal killed gnu pascal).

No, being gcc based killed GPC. It was simply too hard to work with, and major version transitions of GCC were painful.

The authors gave those reasons in their exit message, and said they would opt for a compiler generating C/C++ written in C++ (and maybe later itself) if they had to start over.

Anyway since those years something has changed in FPC, since pas2js exists and also the JVM backend. You could use one of those as basis for a bootstrap.  But IMHO the whole problem is overrated.

[funlw65]

I am very comfortable with Jalv2 compiler of JAL language for PICs, mainly because I can set a development workstation no matter the operating system. It is written in C language and can be compiled everywhere.

Not so much with Great Cow Basic, written in FreeBasic that is not available for all the operating systems. These two are the most complete open source compilers for PICs with a plus for GCB for AVR support. Both come also with their own assembler as gputils is behind regarding the support for the new arrivals.

This is just a minor example (to which I could add the case with the written books and tutorials that you trow away because it refers to old versions of languages that no longer work for your system).

For my needs, freepascal 3.0.4 is more than enough.  But is available for only a few operating systems. And I am interested in DragonFlyBSD for its mp support which is better than in NetBSD and OpenBSD and for its wonderful file system (Hammer/Hammer2). Sometimes, the ABI breaks in these UNIXes and you have to recompile all the applications (and repeat the bootstrap for fpc) and I want to be able to carry that version of pascal from version to version, without disturbing anyone. And without anyone knowing what I need and use (well, too late now) and for what.

For the C language that is affected in time by the change of C standards the solution is simple. I'm using TinyCC statically compiled under Linux with musl and I can stay with C89/C99 standards as long as I want.

Well, no rush as I wait for the Spring to come to set a dflybsd workstation...

[PascalDragon]

Is there a tutorial for bootstrapping  freepascal for a certain operating system?

For an unsupported operating system or one that is already supported but has no binary release?

For the former see this slightly outdated example (though more or less still valid).

For the later see - as marcov mentioned - the buildfaq. Though in short: you need suitable binutils for a host for which the compiler exists and then build it using

Code: [Select]

make all OS_TARGET=<targetos> CPU_TARGET=<targetcpu> BINUTILSPREFIX=<prefix> CROSSBINDIR=<path>
make install OS_TARGET=<targetos> CPU_TARGET=<targetcpu> INSTALL_PREFIX=/path/for/install
<targetos> and <targetcpu> are the names of the OS and CPU for your desired system respectively, <prefix> is the prefix that the binutils use (e.g. aarch64-elf-), <path> is the path where the binutils reside (if they aren't located in $PATH, in that case you can leave out that option) and /path/for/install is where you want to copy the installation to before you move it over to your real operating system.

For my needs, freepascal 3.0.4 is more than enough.  But is available for only a few operating systems. And I am interested in DragonFlyBSD for its mp support which is better than in NetBSD and OpenBSD and for its wonderful file system (Hammer/Hammer2).

Seems like no one was interested enough to create a binary distribution for DragonFlyBSD.

Sometimes, the ABI breaks in these UNIXes and you have to recompile all the applications (and repeat the bootstrap for fpc) and I want to be able to carry that version of pascal from version to version, without disturbing anyone. And without anyone knowing what I need and use (well, too late now) and for what.

Sometimes source adjustments are necessary however as was recently the case with FreeBSD. Then a simple recompile won't help.

[DonAlfredo]

Sidenote about DragonFly.
Various bootstrappers for dragonfly can be found here: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/bootstrappers_v1.0
Fpcupdeluxe for DragonFly can be found here: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.2.0n/fpcupdeluxe-x86_64-dragonfly

[marcov]

I am very comfortable with Jalv2 compiler of JAL language for PICs, mainly because I can set a development workstation no matter the operating system. It is written in C language and can be compiled everywhere.

I just use MP lab X (and xc16) for pics.

Not so much with Great Cow Basic, written in FreeBasic that is not available for all the operating systems. These two are the most complete open source compilers for PICs with a plus for GCB for AVR support. Both come also with their own assembler as gputils is behind regarding the support for the new arrivals.
 
This is just a minor example (to which I could add the case with the written books and tutorials that you trow away because it refers to old versions of languages that no longer work for your system).

For my needs, freepascal 3.0.4 is more than enough. 

That is understandable, but that also means you must stand on your own two feet, as providing detail support for old versions is nigh on impossible for us.

But is available for only a few operating systems. And I am interested in DragonFlyBSD for its mp support which is better than in NetBSD and OpenBSD and for its wonderful file system (Hammer/Hammer2). Sometimes, the ABI breaks in these UNIXes and you have to recompile all the applications (and repeat the bootstrap for fpc) and I want to be able to carry that version of pascal from version to version, without disturbing anyone. And without anyone knowing what I need and use (well, too late now) and for what.

If the ABI, or the linker scheme or the startup code changes, code changes are necessary. Just bootstrapping won't do anything there. If you have made the changes, you usually you can run some Linux or FreeBSD in COMPAT support and then compile for the new API to re-bootstrap. Even simpler than crosscompilation on a different machine.

For the C language that is affected in time by the change of C standards the solution is simple. I'm using TinyCC statically compiled under Linux with musl and I can stay with C89/C99 standards as long as I want.

The problem is that the Unix interfaces are only available in C and not really machine parseable (e.g. the Windows headers are much cleaner in that regard) If *nixes simply provided e.g. STAT record definitions in some easy parse-able format (without umpteen preprocessor defines that need checking through the whole tree) then we could react to ABI changes in a more automated fashion.


But that is something that has to come from the *nix maintainers side. I had a simple script to divine the ELF_IDENTIFIER from some binary in /usr/bin, and even that breaks nearly every other iterations. Maybe you can prod Matt ?

Well, no rush as I wait for the Spring to come to set a dflybsd workstation...

I can wait, no problem.

[funlw65]

Wow, thank you guys for understanding, insight and support, really appreciate it!

Sometimes source adjustments are necessary however as was recently the case with FreeBSD. Then a simple recompile won't help.

That is understandable, but that also means you must stand on your own two feet, as providing detail support for old versions is nigh on impossible for us.

If the ABI, or the linker scheme or the startup code changes, code changes are necessary. Just bootstrapping won't do anything there. If you have made the changes, you usually you can run some Linux or FreeBSD in COMPAT support and then compile for the new API to re-bootstrap. Even simpler than crosscompilation on a different machine.

For the C language that is affected in time by the change of C standards the solution is simple. I'm using TinyCC statically compiled under Linux with musl and I can stay with C89/C99 standards as long as I want.

The problem is that the Unix interfaces are only available in C and not really machine parseable (e.g. the Windows headers are much cleaner in that regard) If *nixes simply provided e.g. STAT record definitions in some easy parse-able format (without umpteen preprocessor defines that need checking through the whole tree) then we could react to ABI changes in a more automated fashion.


But that is something that has to come from the *nix maintainers side. I had a simple script to divine the ELF_IDENTIFIER from some binary in /usr/bin, and even that breaks nearly every other iterations.

This definitely needs a change in my strategy regarding my future "retiring" (well, one cannot really give up on Linux, ever [or RAD Pascal]) in the UNIX world and still remaining relevant for crossplatform development. I see how this is a continuous battle for the dev team.