Forum > General
Bootstrapping
marcov:
--- Quote from: funlw65 on November 17, 2022, 02:34:14 am ---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.
--- End quote ---
I just use MP lab X (and xc16) for pics.
--- Quote ---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).
--- End quote ---
--- Quote ---For my needs, freepascal 3.0.4 is more than enough.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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 ?
--- Quote ---Well, no rush as I wait for the Spring to come to set a dflybsd workstation...
--- End quote ---
I can wait, no problem. ::)
funlw65:
Wow, thank you guys for understanding, insight and support, really appreciate it!
--- Quote from: PascalDragon on November 17, 2022, 07:19:37 am ---Sometimes source adjustments are necessary however as was recently the case with FreeBSD. Then a simple recompile won't help.
--- End quote ---
--- Quote from: marcov on November 17, 2022, 12:13:33 pm ---
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.
--- Quote ---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.
--- End quote ---
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.
--- End quote ---
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.
Navigation
[0] Message Index
[*] Previous page