Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
No, FPC's or the RTL's sources aren't needed to compile programs, of course. If the compiler seeks for syspara.inc, it means it already started to (re)compile a system unit, so it found a system.pp. Don't be in the rtl/atari directory, when trying to compile a hello world.
Or don't specify the path to that source. Specify the path to the pre-built *.ppu files instead using the -Fu argument.The "fpc" binary is just a compiler frontend, mostly useful if you're have multiple versions or CPU targets installed. You're safe to call "ppc68k.ttp" directly instead. This issue is because I never implemented environmental variables support (are they even a thing on TOS?) for Atari, neither querying the path, so the compiler can't see what's in the path. An alternative solution or workaround for now is using the -FD argument, to tell the compiler with an absolute path where it finds various external tools and utilities. (That applies to vasm/vlink too.) ... Maybe the first thing to implement going forward?
Oops, right.
Oh, i somehow missed them. But i bet they are compiled by vc, using vclib. Maybe does not matter much in this case, but mintlib usually support MiNT much better.There are vasm binaries with std syntax available for TOS/MiNT, on Frank Wille's page
There is normally no need to distinguish the two. There are of course functions in MiNT that are not supported in TOS, but its up to the user (and maybe partly the system libraries) to handle that. If you do it properly, you can run the same binary both on TOS and MiNT. Using separate targets would be confusing, and require the user to also compile his programs for both targets.
I did try that as well but the build stopped while looking for the system.ppu.
Caused by missing or incorrect -Fu parameter, to specify unit paths. There isn't anything magic in this. The compiler needs to know a couple of paths, one is to the unit files (-Fu), and another one to the tools to use (-FD parameter) and then it should work. See the ppc68k command line on my example screenshot. That really has everything you need. (The * at the end of the -Fu parameter says, "look into every directory, within this directory", so you don't need to specify every directory one-by-one in this case.)
If it helps, Marcus Sackrow's FPC/Amiga buildsystem also provides "raw"/"nightly" Atari builds. The archive on this link is updated regularly with the newest build: http://build.alb42.de/fpcbin/fpc-3.3.1.atari.tar.gz
This error message is _not_ from Free Pascal, but from vasm. It looks like somehow the called program inherits ppc68k's command line options, so "-Fuunits/atari/*" gets passed to vasm. I don't know why or how, it clearly doesn't happen on my setup, and there's no code in FPC do to so. -F option of vasm selects the output module, hence the error message.
Code: Select all
result:=gemdos_pexec(0,PChar(tmpPath),@pcmdline[0],nil);
Theoretically, that should not happen. mintlib should only use ARGV, when the command line length is set to 127, which does not happen in fpc. But i agree that the problem really looks like being caused by this.ChainQ wrote: ↑Wed Jan 26, 2022 11:47 pm If I can have an educated guess, this is somehow related to the fact that we pass "nil" (a.k.a. 0L) to pexec "env" there, and according to TosHyp documentation, that makes the child process inherit the parent's environment, which in this case must somehow include ARGV things, which FPC doesn't touch currently.
Oops. My bad. No, thats not a vasm problem. I was not using a nightly snapshot, but latest release 18l. But i added a debug printf somewhere that i forgot to remove.1., gonna report this problem to Frank Wille
That will be gone if at least the startup code supports ARGV.And then of course, input is still welcome regarding the above pexec problem.
No worries, at least there we have an explanation. And then after all it's good that I'm a slacker, and did not sent that email yet...ThorstenOtto wrote: ↑Thu Jan 27, 2022 6:06 am Oops. My bad. No, thats not a vasm problem. I was not using a nightly snapshot, but latest release 18l. But i added a debug printf somewhere that i forgot to remove.
I don't see how, I mean ExecuteProcess code should still do the env copy itself and omit ARGV= (or add it's own depending on the command line length) no? BTW, I had a stab yesterday under EmuTOS (as I don't have a working FreeMint setup, and definitely no time to figure that one out now) to get something like this working. I tried to parse the env pointer in the basepage, but I only see a PATH= variable, with C:\ as value, and nothing else. Which is weird for multiple reasons, for example I added some more directories to the PATH (with the "path" command in EmuCON), but they don't seem to appear there. Neither can I see an ARGV= variable, which is double-weird, because if the thing is optional even on recent TOS remakes, then we can't reliably implement argv[0] (executable name). So I'm at a bit of a loss here.That will be gone if at least the startup code supports ARGV.And then of course, input is still welcome regarding the above pexec problem.
No it does not have to remove ARGV, that's task of the startup module. But that does not happen currently, so if you use a shell that uses ARGV, and Pexec() is called with env=null, programs that are invoked from within fpc (or ppcm68k), like the assembler or linker, will see the ARGV that was passed from the shell. But as noted above, they should ignore it if the "normal" commandline does not indicate that ARGV is in use, but apparently something is going wrong there somewhere.
That's because EmuCON does not use ARGV.Neither can I see an ARGV= variable
Don't worry, i'll take care of that.So I'm at a bit of a loss here.
For plain TOS, you can use Hatari for that. For Mint, you have to use ARAnyM, because MiNT gets in the way with Hatari's gemdos emulation. Vincent posted a video some time ago to get ARAnyM+MiNT running (that was for Windows, but its not much more difficult on linux). Only problem is that there are currently no daily snapshots available for aranym. There are also premade images available with some tools installed; you can still boot from that image, then add some host holder in the config file to share your data.(shared folder with the host OS would be ideal).
Depends on the desktop. I think bash always uses ARGV, regardless of commandline length. Some desktops try to be clever and only use ARGV when it is longer than 126 chars. But actually that isn't that clever, since without ARGV the ttp cannot get a reasonable value for argv[0].
The aes unit is part of the tosunits package. It's part of the default build for Atari, obviously, so it's in that fpc archive I already linked, under units/atari/tosunits.
Just this log isn't really helpful. For example your unit search paths are not visible in it. Full logs can be written to the disk: instead of -va, you might want to use use -veiw -vv. In this case, a more manageable set of information is displayed on the console window and the detailed log (-vv argument) is written into a file called "fpcdebug.txt" in the build directory. This file then can be shared easily or read after the build, when diagnosing issues. (Note the file is appended if it already exist, so you may want to delete it between runs.)