64-bit hosted on Linux

[magorium]

Sure, but regardless of the environment the compiler lives in, it would still have to produce code that would work on an AROS I have access to.

Of course. But if you use the same eco-system for all, f.i. ABIv1 then you can use the main build-system that also creates AROS to build the cross-compiler for you, download&install the (linux) hosted version, use contrib to extend your hosted installation, use the cross-compiler to compile code, move it to your hosted setup and test your executable there.

(Hm, that would allow for AROS running on the A600, now that I think about it. I wonder ...)

Yes, that works. I (have) ran AROS on a a4000. AROS is pretty memory hungry though so you won't be able to enjoy without some expansion.

In case you wish to test then you can use a emulator (fs-uae f.e.)

OK. Running into several problems here. Somehow, it seems my scripts in S: are not being recognised as scripts by the mere fact that they are in S:. I wonder if I miscopied something, or ABIv11 doesn't support that as yet.

I tested it myself just before posting that message so it should be able to work for you as well. I use double commander to extract the archives so in case you are using something else or use a terminal then your mileage might indeed vary.

If more help is required then I would have to be able to reproduce what you did in order to figure out a solution, so give a shout in case you wish to go that route.

assign developer: system:Development

Indeed, and if I remember correctly then that must be changed to read :
assign development: system:Development

At least if memory serves me correctly then that is what ABIv11 uses for assignment of/for its compiler directories.

S:DeveloperShell-Startup

Ah yes, that one 

No idea what the ABC shell is supposed to be,

A Bourne Compatible shell (such as sh).

but it would be nice to be able to compile something more useful.

I am not a c-programmer but if everything was installed correctly then the AROS includes are part of the installation (that is why the need to copy development directory from contrib over to your hosted development directory (and make it overwrite)) and you should be able to compile something that uses AROS API's. In that regards you should be able to follow any guides/examples that are part of www.aros.org or the AROS wikibook.

[magorium]

If more help is required ...

The following is as basic as it gets.

In a terminal execute the following commands (afaik the untar command will automatically overwrite)

to create temporary work directory in your homedir (can be anywhere else where you have sufficient rwx rights):

Code: [Select]

cd $HOME
mkdir work

to download and extract AROS-ABIv11 x86_64-Linux hosted system files:

Code: [Select]

$ wget https://www.axrt.org/download/aros/v11/AROS-20230430-1-linux-x86_64-system.tar.bz2
$ tar -xf AROS-20230430-1-linux-x86_64-system.tar.bz2

to download, extract AROS-ABIv11 X86_64-bit contrib archive and patch DeveloperShell-Startup sequence:

Code: [Select]

$ wget https://www.axrt.org/download/aros/v11/AROS-20230430-1-any-x86_64-contrib.tar.bz2
$ tar --directory ./AROS-20230430-1-linux-x86_64-system --strip-components=1 -xf AROS-20230430-1-any-x86_64-contrib.tar.bz2 AROS-20230430-1-any-x86_64-contrib/Development
$ tar --directory ./AROS-20230430-1-linux-x86_64-system --strip-components=1 -xf AROS-20230430-1-any-x86_64-contrib.tar.bz2 AROS-20230430-1-any-x86_64-contrib/S
$ sed -i 's/Developer/Development/g' ./AROS-20230430-1-linux-x86_64-system/S/DeveloperShell-Startup

to download and extract some example source-code:

Code: [Select]

$ wget http://archives.aros-exec.org/share/development/example/mui_examples.i386-aros.zip
$ mkdir ./AROS-20230430-1-linux-x86_64-system/Work
$ unzip mui_examples.i386-aros.zip -d ./AROS-20230430-1-linux-x86_64-system/Work

to boot AROS hosted on linux, providing AROS with 1024 MB of memory:

Code: [Select]

$ cd AROS-20230430-1-linux-x86_64-system
$ ./boot/linux/AROSBootstrap -m 1024


Then, in AROS open a (new) shell using the workbench menu and in the shell type:

Code: [Select]

> execute S:DeveloperShell-Startup
ABC shell will open, continue with:

Code: [Select]

> cd Work/MUI_examples/01_Window
> make
> 01_Window

Play with the window, finally exit the demo example and try to compile something else.

Compiled executables can be ran on any other AROS ABIv11 (distro).

[Mysha]

Sure, but regardless of the environment the compiler lives in, it would still have to produce code that would work on an AROS I have access to.

Of course. But if you use the same eco-system for all, f.i. ABIv1 then you can use the main build-system that also creates AROS to build the cross-compiler for you, download&install the (linux) hosted version, use contrib to extend your hosted installation, use the cross-compiler to compile code, move it to your hosted setup and test your executable there.

You've lost me here: Are you talking about Big-Computere-On-Internet compiling for ABIv1,  which will somehow result in ABIv11 compliancy? Or are we talking about one of my computers, that I somehow instruct to produce code that will be ABIv11 compliant?

(Hm, that would allow for AROS running on the A600, now that I think about it. I wonder ...)

Yes, that works. I (have) ran AROS on a a4000. AROS is pretty memory hungry though so you won't be able to enjoy without some expansion.

Hm, talking about AROS being a rather lean OS?

OK. Running into several problems here. Somehow, it seems my scripts in S: are not being recognised as scripts by the mere fact that they are in S:. I wonder if I miscopied something, or ABIv11 doesn't support that as yet.

I tested it myself just before posting that message so it should be able to work for you as well. I use double commander to extract the archives so in case you are using something else or use a terminal then your mileage might indeed vary.

I wouldn't know how to create that, yet. But it doesn't seem to do much more than what Caja does on Ubuntu Mate, so I'll leave that for now. Still, thank you for indicating the option, but as the target machine is checking a 32T harddisk at the moment, I couldn't go that route anyway. (At least, not easily; the A600 isn't normally linked to the net, and I'd need to figure out how to sneaker-net to it by floppy.)

If more help is required then I would have to be able to reproduce what you did in order to figure out a solution, so give a shout in case you wish to go that route.

OK, once disk checking is over, I'll let you know how I fair.

assign developer: system:Development

Indeed, and if I remember correctly then that must be changed to read :
assign development: system:Development

See, that's why I keep feeding back until we agree. OK, I added that assign, but at the time it didn't have the effect I wanted. I'll do a more thorough check later.

I am not a c-programmer but if everything was installed correctly then the AROS includes are part of the installation (that is why the need to copy development directory from contrib over to your hosted development directory (and make it overwrite)) and you should be able to compile something that uses AROS API's. In that regards you should be able to follow any guides/examples that are part of www.aros.org or the AROS wikibook.

Do the AROS wikibook now have official standing? But, no, the AROS API's were not included. Thanks for analysing the problem so far; it'll be part of the aforementioned more thorough check.

[magorium]

You've lost me here: Are you talking about Big-Computere-On-Internet compiling for ABIv1,  which will somehow result in ABIv11 compliancy? Or are we talking about one of my computers, that I somehow instruct to produce code that will be ABIv11 compliant?

The latter. You, the developer, decide for which eco-system (I do not have a better name for it in English) you wish to use and/or either compile for. It does not matter using a native compiler and/or a cross-compiler as long as the eco-system (ABI, same up to date version of the used source-code to build AROS and contrib etc) matches.

Hm, talking about AROS being a rather lean OS?

If you do not have a pimped up Amiga then AROS is slow as a snail crawling through mud.

I wouldn't know how to create that, yet.

Depending on your distro part of the package manager.

But it doesn't seem to do much more than what Caja does on Ubuntu Mate, so I'll leave that for now.

It would indeed be similar though not having used Caja for ages (despite running mate myself at Debian (not Ubuntu))

OK, once disk checking is over, I'll let you know how I fair.

In the mean time I had time to post detailed instructions on how to setup ABIv11 (see my previous post).

Something similar is possible to achieve for ABIv1, though then relying on a cross-compiler in case wanting to compile on your Linux rig. Last time I've tried that involved A little bit more work. Also note that I do not know the state of the (native ABIv1) 68k compiler (in case there is one).

See, that's why I keep feeding back until we agree. OK, I added that assign, but at the time it didn't have the effect I wanted. I'll do a more thorough check later.

Note that for ABIv1 (in comparison to ABV11) the assign is correct. Different  ABI's, apparently mean different solutions.

Do the AROS wikibook now have official standing?

No. But the difference in ABI does (normally) not affect user space code. For normal user space code the only thing that matters between ABI's is binary incompatibility.

But, no, the AROS API's were not included.

For user-space code it (again) does not matter. The compiler and includes automatically take care of the ABI differences, unless specifically relying on an ABI defined/used incompatible feature/structure.

Thanks for analysing the problem so far; it'll be part of the aforementioned more thorough check.

You're welcome but I do believe you are complicating things a little there perhaps by too much overthinking ?

Normal programs can use the same source-code and compile them for whatever ABI to result in a binary that is incompatible between the different used ABI's. And that is actually all we have to care about unless code is relying on a ABI specific feature (and frankly there is none I can currently think of that might have any impact unless wanting to rewrite/fix something inside the kernel itself).