ah well:



ends up for me into:



So where did i go wrong and perhaps more importantly how to approach to be able to tell myself ?

Frankly, i am at a loss right now ...

Quote:
Indeed.

And to digress: yes, the Pi is underpowered for this kind of job (some simple cross-development should be fine though) and yes i fail to understand what was wrong (there wasn't anything wrong imo) with Nick asking for what he asked.

You simply use the right tool for the job at hand and for him it was what was asked for. Not that he was asking for a beefed up Macbook Pro or ROG G703G or something like that just because the funs of it.

That thread was a total non-discussion imo, hence my absence.

Quote:
Ah, but i am a quitter... did you not know ?

But on a more serious note, currently our life is a mess (to be more precise, the housing situation is) so i'm currently not in any mood to spent time cursing at a failing buildsystem :ducks:

Quote:
maybe that explains what nick was about when talking about appropriate development system.

Quote:
but cmon, i usually do that day for day for different targets, and regularly from the scratch. dont easily give up! ;)

Quote:
Now i do know

It is related to memory issues, so try to increase your swap.

On Raspbian that can be done like mentioned here, although it required a reboot for me in order for the new size to take effect. I have it set to 2048, perhaps you could try with something a bit smaller as it slows things down considerably.

For some obscure reason package texinfo was not installed for me so that borked building the compiler, but after that things builded smoothly. The newer gcc is a beast though, and took me 2 hours to compile. Seems to work like a charm when setting the sysroot to correct path for the includes..

After building the compiler, building AROS failed within 10 minuites for me with undefined symbols (memset) when trying to build linuxinput.hidd

That is where i throw in the towel for the time being.

Quote:
No problem at all of having a small sidetrack

Quote:
The aim is to let someone who surfs over to the nightly download page for AROS running on pi be able to compile the AROS themselves if wanted to. The gimmearos.sh script should work, and it does with the exception of the outdated presicion library URL and some small improvement on the gimmearos-script (who's changes/fixes also applies for the v1 script).

Because i do not have the same setup as the build-server and having the wrong link to mpc in the makefile, the build fails for me (and for anyone else trying to compile hosted arm).

I would have thought fixing that would appeal to your project of being able to reproduce everything

fwiw: this vs this as i assume that is used for the hosted arm nightly's posted on the ABI-v0 page as well..


Quote:
I do not disagree with that, other then backports are still being commited. It isn't worth the hassle of forking the project simply for changing one simple URL in a mmakefile.src and updating and/or providing a script that also works on/for the pi.

Quote:
I am aware of michal's project(s), but that does not take away the fact that things (as provided to the end-user) should just work. It is what annoys me to hell, to let things rot even further.

Mind that i'm talking about v0-on-trunk (which Icaros is based upon as well), and not talking about the abandonded v0.

Quote:
No problem as your input (and contributions) is (are) appreciated.

fwiw it is not about my personal endeavour, rather to fix things that are presented as something that should work out of the box

Yes, v1 is attempting to build as well, but it isn't going very fast

i dont want to hijack this thread, but i think it might be easier and more future proof and sensible to invest work into building abi v1 on arm/rpi. first of all, contrary to i386, compiling abi v0 would not benefit of any existing ready to go software library. secondly avi v0 has been declared obsolete. all efforts beyond sustaining it on already supported platform, which is solely i386, will be wasted, as soon as transition to abi v1 effectively occurs. on the contrary: trying to fix and extend obsoleted branch is counter productive since it could negatively impact on what effort should be dedicated to, namely getting aros actually forward. i am mentioning it in particular because just lately, as known, michal started to work on arm/rpi big endian target, which can seriously impact reception of aros among amiga and rpi audience.

that said, i dont want to pick on anybody and their personal endeavour, bless them, just to indicate what might be sensible in a general scope.

super interesting thread, but I hope you guys have direct connection with each other, or ate least through the dev irc, as it will give you faster and easier feedback.

Anyway, keep trying! what you are doing is very important.

Quote:
Yes, it is quite possible that you (already) have those files when using either another distribution on your pi or in case you have already fiddled with your setup in the past.

Note that the missing files afaik is only a culprit on/for Raspbian. Also note that i was using Jessie. Most people would be using Raspbian i guess ?

Next step for me could be to try something like Tiny Core or something like that, and the milage may very well vary in that case (only one way to find out )

I look at it from another perspective in that someone could start from scratch. In which case this link should be read first. Then the gimmearos script (together with the additions/fixes i've mentioned in this thread) should get things going.


Quote:
Do note that simply putting the 'missing' files at the correct location isn't going to get you a compiler able to compile Aros compatible executables. GCC and binutils require patching.


Quote:
Ah yes, i seem to remember having ran into something similar to that as well but that was when i mistakenly build aros-raspi, which failed somewhere along the line but did produced a compiler for me (AROS build itself failed there). In my recollection the wrong linker was invoked from that compiler and i did not know how to fix that (on short notice and without borking my setup).

Quote:
As stated above, i believe (so take that with a grain of salt) it's due that the wrong linker is being invoked (ld of your system, instead of collect-aros).

Quote:
Again note that removing multilib was only required for me on Raspbian. I did not try the v1 script yet as pi-hosted is based on v0-on-trunk, but i assume it should not be a problem to compile with ABI-v1 sources.

i have no idea what "target 's-automata' failed." means. Try to invoke your gimmearos script (or better yet your own modified version or shortscript) with piping output and error channels with tee into a file and post the results (well the interresting bits that is, otherwise you will use up the storage of the forums ).

Quote:
I am by no means proficient with patching gcc, let alone doing it manually (that is why i use the gimme aros script (my modified one) and let the AROS build-system figure things out for me).

I'm also not proficient enough with the build options other then it is custom to build (AROS) outside the source-tree (which is what gimmearos script does as well).

In case you would want to attempt by doing things out of the box then i would probably suggest to take it up with the developers mailinglist. As you've probably noticed i'm already out of my comfort-zone..

In case things are not working for you with the gimmearos script then feel free to post some output so that it is possible to address the culprit(s). Do note that mixing the v0 and v1 scripts (or actually the produced files) is not convenient as they are incompatible, so make sure to clean up things when attemptng a new run.

fwiw: I'm assuming that you've modifed your gimmearos-script to include the modifications i've mentioned in one of my previous posts.

Quote:
You could also compile from within Aros itself if wanted.There should be a unix shell and gcc compiler present. I realize that the benefit of running hosted is that you are able to use your host's software, but in case all else fails

@origami

Thank you for all the help, here is an update from my side on this.

All the needed header files as mentioned were already installed on my system when I checked it.

I fixed the <tt>configure</tt> script to include the missing directory, probably an good fix (I think). There is already some additional directories for Ubuntu 11.10 and Debian, so I simply added the missing one for Raspbian on another line in a similar way. I dumped all variables it had and it was not possible to generate the needed directory from them. I query gcc for the machine (which is that arm-linux-gnueabihf) and put it together in a similar way as that Debain thing.

After this it could find that <tt>sys/cdefs.h</tt>.

However, it failed a bit later on with a mismatch on that an object files uses VFP regisers but <tt>libautoinit.a(startupvars.o)</tt> does not. I assume it means the library is built with soft floats. I configured it with hard floats as suggested. I have no clue.

So I switched to using gimmearos-v1.sh, commented away gcc-multilib and after some chewing it concluded that recipe for target 's-automata' failed.

Now I will go in another direction, as I do not really think I need to build it at this point. I will take a look at how gcc is patched. I managed to use the built-in native gcc using the thin AROS shim on top and compiled AROS binaries with it. I am curious to see if it is really needed to use these cross compilers, or if the native one actually can do.

Then I can try hostlib, which could help me do what I wanted to do in the first place.

@origami

Thank you for all the help, here is an update from my side on this.

All the needed header files as mentioned were already installed on my system when I checked it.

I fixed the <tt>configure</tt> script to include the missing directory, probably an good fix (I think). There is already some additional directories for Ubuntu 11.10 and Debian, so I simply added the missing one for Raspbian on another line in a similar way. I dumped all variables it had and it was not possible to generate the needed directory from them. I query gcc for the machine (which is that arm-linux-gnueabihf) and put it together in a similar way as that Debain thing.

After this it could find that <tt>sys/cdefs.h</tt>.

However, it failed a bit later on with a mismatch on that an object files uses VFP regisers but <tt>libautoinit.a(startupvars.o)</tt> does not. I assume it means the library is built with soft floats. I configured it with hard floats as suggested. I have no clue.

So I switched to using gimmearos-v1.sh, commented away gcc-multilib and after some chewing it concluded that recipe for target 's-automata' failed.

Now I will go in another direction, as I do not really think I need to build it at this point. I will take a look at how gcc is patched. I managed to use the built-in native gcc using the thin AROS shim on top and compiled AROS binaries with it. I am curious to see if it is really needed to use these cross compilers, or if the native one actually can do.

Then I can try hostlib, which could help me do what I wanted to do in the first place.