Quote:
See my previous post on how to setup an AROS build environment. There are some issues here and there that i've hopefully managed to address for you.

With regards to weakness, it depends how patience you are. a full build on my pi3b (no overclocking) took about 3 hours. It depends a little on your internet-speed as well.

I still have to try and build it from a external usb HD to see if that makes things considerably faster. For the occasional build its good enough for me. I even cross-compile to mingw for my Windows rig as that is a PITA to do on Windows itself.


Quote:
An example on how to use hostlib.resource can be found inside the aros source-tree here.

Quote:
In theory anything like that is possible. The question is more or less do you wish to spent the time on it. For example Janus (amiga 68k emulator) can runs seemless within Aros and if you would ask the developer who implemented that, it is a PITA do be able to do it right.

Quote:
Hosted will be able to do that for you indeed, if you are into that.

The whole Aros project is interesting for me personally because indeed it has the same API and the OS itself has the same look and feel as classic AmigaOS did.

Things are clear and simple for me (even for noobs), especially the shell. The workbench can be a tad intimidating (especially when using a workbench replacement like dopus) but you can get used to it pretty quick.

Quote:
Yes, the latter is something we all have to deal with. In the end it is just a hobby and for me pure fun. The lack of drivers (and developers spending time on those) is a drawback so that is one of the reasons why hybriding Aros with Linux seems a good idea to some. The longer the Aros project lingers the more i'm inclined to agree with that point of view, even though things haven't matured in full for Anubis and Arix.

Quote:
I totally agree to that.

Hi hth313,

sorry for the delay as things are kind of hectic around here. I was in the process of verifying some things in order to be able to build AROS hosted for the pi on the pi.

First, i assume that you know your way around bash script so that you are able to read/understand the gimmearos script that is supplied in the scripts directory inside the sources.

I take that script as a base and you would have to use my instructions to make sense out of it (i did not have time to correct the gimmearos script)

Let start with some education. In order to figure out what particular file resides in what packages you can make use apt-find. But afaik that is not installed by default.

to install the apt-file command: sudo apt-get install apt-file
to update it's database: sudo apt-file update

The latter should also be possible as to invoke with user rights (so without sudo)

then we can find for files: apt-file find cdefs.h
and while you are at it, also do a: apt-file find Xcursor.h

remember the names of the relevant packages.

then: sudo apt install libxcursor-dev
and: sudo apt-get -reinstall install libc6-dev

Alas the latter has a quirk in that it install things inside /usr/include/arm-linux-gnueabihf where you can find the includes. Note the sys directory.

As i did not wanted to mess with the include paths i simply copied the contents of the ....gnueabihf directory to usr/include in order to satisfy the compiler.

Perhaps the above is not the smartest idea but if someone got a better solution then please come forward and express those solution(s).

Another problem that occurs along the way when building aros is that the url to multiprecision library is pointing to the wrong url (the package moved). balaton committted a fix for that in trunk but was not backported to ABI-v0 on trunk.

If a developer reads did then would someone please be so kind as to backport that commit so that on trunk is compilabe for us mortals ?

we need to do it manually for now, so assuming that you had downloaded the source-code from the aros.org website and extracted the archive do a grep:
> grep -rn 'path/to/directory/where/your/sources/are/located/' -e 'multiprecision'

now, i do not remember the name of the file from mind bu check those files and modify the mmakefile.src where the url points to www.multiprecision.org (or something like that and make it point to the gnu ftp url where multiprecision library is now located. put the new url in front of the others that are listed and save your file.


Ok, so now that we did some preparations, let's take a closer look at the gimmearos script as linux-arm target is not avaiable in there.

1) install the required packages that are listed under option 1. Do note however that gcc-multilib is not present in the package manager apt, so we need to exclude that package from installing.

2) step two is the source-code but you already had that downloaded and extracted. note that i refer to that directory name as being $srcdir (as compliant with the gimmearos script). Do note that one directory up from your directory where your sources are is your current dir ($curdir)

3) configure
> cd "$curdir"
> mkdir -p "$portsdir"
> mkdir -p "aros-linux-armhf-v0"
> cd "aros-linux-armhf-v0"
> "..$srcdir/configure" --target=linux-armhf --with-portsources="$portsdir"
The with-portsources option prevents from downlloading those files again and again with each config/build

4) then the build:
> cd "$curdir"
> cd aros-linux-armhf-v0
> make $makeopts
> make $makeopts contrib
> make $makeopts ports

that should be able to finish the complete aros hosted arm build for you on a pi

Now, you can find the (cross) compiler inside aros-linux-armhf-v0/bin/linux/arm/tools/crosstools/ such as arm-aros-gcc and friends. you would need to supply the complete path to the compile though or make use of scripts/links if you want to use a less tiresome path.

hope that helps you out (a bit)

Quote:

if this is just a netbook from a closet, why not set up fresh linux environment that will provide these packages. imho the dependencies are rather regular and expected to be found without problem on major distributions. i know people are using centos, i myself used ubuntu, plain debian and later refrained to lubuntu due to annoying desktop behaviour expected with other distros under vm.

Quote:

I have played with the build system a bit now, but I just run into problems.

There is a <tt>@tex</tt> tag problem caused by newer Texinfo on the old <tt>gcc.texi</tt> used. It is easy to work around by adding a couple of newlines.

After some struggles building outside the source tree on the RPi and then the x86 netbook where it had massive problems related to packages it depended on (I did not even got it to really start building), I switch back to the RPi and tried building inside the source tree.

Inside the source tree it runs for a while, then it fails to find <tt>sys/cdefs.h</tt>. It uses the cross compiler it built, but makes use of system header files as far as I can see. This <tt>sys/cdefs.h</tt> is included from <tt>//usr/include/string.h</tt>. The file does not exist, simple as that. Some googling seems to indicate that this can be the case if you are running a 64-bit system and try to build 32-bit binaries, in that case install the 32-bit C library. Now I am running only 32-bit, so that advice does not really help.

It is also protected by <tt>#ifndef _SYS_CDEFS_H</tt>. Doing a find-grep in the source tree gives that there are variants of this, it uses <tt>SYS_CDEFS_H</tt> and <tt>_SYS_CDEFS_H_</tt>, but not <tt>_SYS_CDEFS_H</tt>.

I wonder why it uses the cross compiler on system include directories? Is that intentional or should it not come with its own header files? On the other hand, it is building hosted, but then why does it use the cross compiler?

Quote:

I am in the process of setting up a build environment, trying to make it build on the RPi. I also took out an x86 netbook that have Linux installed from the closet, in case the RPi proves too weak for this.

I managed to get my POSIX calls to work, but to AROS actually, as it turns out that AROS provides a limited set of POSIX calls, and the ones I were using was there. Using a proper Amiga command instead of a Linux one made it work quite nicely. This was not my plan, but nice to see.

Quote:

Cool! This is probably what I am looking for, and definitely I should be using that lock mechanism. The documentation does not mention which file to include, which is a pity. I can always grep for it and it came up with some suggestions and none really felt like like the clear winner as the "main one".

There is no agenda here really, other than trying to learn things and run it hosted. I kind of think I could have icons to start Emacs for example, then the Emacs could appear (kind of) in the same screen as the rest of AROS and I can develop inside Emacs, accessing the AROS file system, editing and building. Hopefully giving the feel of having a real Emacs for AROS, more or less.

Quote:

My end goal is basically understanding the architecture and how it tames the tools. This is because I am interested in such matters. I also have some hope running something like an Amiga, perhaps to try and program with the Amiga APIs while still having a Linux/OpenLook machine around it at the same time. Having the best of both worlds.

While I think it may be a good idea to run AROS on top of Linux in a more integrated way, I am quite happy learning what is there at the moment. I have enough other projects that I cannot possibly see how I can find time to go deep into this long term. As everyone else, I need to put food on the table.

So no, there is no plan from my side to try and repeat anything similar to what was tried in the past. I currently believe more in a gentle evolution on what is already there, perhaps getting a bit better focus on things. However, I have no illusion that I will be able to change the world here. The only minor hope I have at the moment is that there can be a bit more focus on the RPi, as I think having a small number of reference platforms could help getting things into an even better shape, making it easier to set up a working system, thereby increasing the chance that people get interested and use it.

Quote:
thats exactly what build scripts to be used in aros build system meta makefiles will spare you.. mostly.
these macros are implemented and documented in config/make.tmpl in case whomever dont know this.

k, thank you hth313.

fwiw i think i see my error (checking out wrong branch). Build is slooow though

Quote:
You still would need a compiler that is able to target Aros, so would need to have to setup a proper build environment. the compiler and binutils needs proper patching (patches are available in AROS source tree).


Quote:
I'm almost certain (judging by the rest of your answer that follows) that this is not what you had in mind but such thing can already be done on hosted by using hostlib. It allows you to make calls to Host OS.

Quote:
Looks like you had something similar in mind as amithlon perhaps ?. If that's the case then have a look at old Arix sources (ezrec's github (or gitorious) is the only place i was able to find them.

Or better yet, have a look at michaels patreon, where another atempt at Arix is made (but that is Arix with a twist/different flavour)

Quote:
Nothing wrong with that. Just don't waste time on things already attempted (in which case you could do a search for Anubis as well .

Quote:
IF you're new to Aros then the best thing is to get yourself familiar with the Aros build-system. I'm still struggling myself with that though (c, config and make-files are not really my cup of tea)

@origami

I downloaded the SDK from the nightly, v0 ARM hosted.

That is probably not the ideal variant to actually use. I was interested in how it worked for developer that wanted to build for AROS, not fiddling with AROS itself. Such person would presumably install the SDK and work from there.

I plan to experiment using calls to POSIX to see if that can be done. Actually, I have already started a bit, but have not got much out of it yet. Sort of trying to make a hybrid AROS/Linux binary for AROS. My overall goal it to get a better understanding of the architecture.

I have downloaded the AROS Git archive, but have not done much with that yet.

@hth313:
Out of curiosity, which AROS sources did you checkout (vo/v1/on trunk) ?

I'm trying to improve some things with regards to the gimmearos script but compiling AROS itself fails miserably for me and fwiw the sdk script was written with i386 in mind (so that isn't going to work ootb either).

note to self: in their infinite wisdom raspbian does not have gcc-multilib listed in packages because "there is only 32 bit raspbian that is supported").

Just a minor update on this.

After fixing <tt>collect-aros</tt> to match the emulation on the host (RPi Linux), the linker (<tt>ld</tt>) stopped complaining and emitted a binary for AROS. Copying it to C: in the installation confirmed that it works in the AROS shell!

Now I will ponder a little bit over this emulation and the SDK, then probably take it to the dev mailing list.