@kas1e

You sum it up nicely. Thank you.

I am quite happy for the upcoming challenges.

@abalaban
Sure,

Quote:

@flash
I agree. Let me quote the relevant part I created:
Quote:
I understand how using an cross-tool-chain is more convenient. Also, how CoreUtils cannot necessarily be trusted when ported to the Amiga. But, there is just something about being able to to do it on the Amiga that I like. This meant the need to have RM -RF working in Makefiles when porting over other projects. Hence why this whole thing started.

It now means that I need my favourite editor / cscope / ctags. So, trying to get a version of Emacs is something that I have to have. I have used Emacs for too long to try anything else because my fingers have now been molested after 12 years of use.

So, what I will try and do in the upcoming days is - on my X1000:
- get the latest SDK installed
- replace the 4.2.4 compiler with a much later version of a compiler,and,
- forcefully overwrite the SDK/CLIB2 with latest one I compiled

@kas1e
Thanks, but this is where I am a little confused. Why is it that I did not know about that? Let me quote my relevant part in the wall of text above:
Quote:
You buy an AmigaOne and you download the SDK from Hyperion. Generally, you would assume that is all you need. You do not have any idea that at this point in time everyone is using a totally different version of CLIB2 and different versions of this and that.

I am not criticising, I am just wondering if I have missed something obvious and if I have not I am wondering how we can make it easier for new people coming onboard.

===EDIT===
Actually, there is: https://forum.hyperion-entertainment.com/. This has some interesting information which I could have also used. I will bookmark that page also.

@LiveForIt

Hello,

really? The only thing I have in my BDH0 is my "amigaboot.of" file.



proves which version of the "driver" I am using, right? Notice that I am not using

Hello,

yes, I use 53.12. I have just commented out that section of the startup-sequence.

Regards.

Actually, confirmed that RM does now work with the latest SDK (53.34) vs SDK (53.30 for which you needed to separately download CoreUtils and all RM, CP etc went through the "coreutils" binary). I literally just wasted a few days of my life. But, I guess I learned a lot.

Okay, so here is the update:

======Update======
So, the issue regarding gethostname is solved by using -D__NO_NET_API, and Olaf uses this regularly in his other projects.

This means that it should be:

Getting us further to:

We still have this issue regarding "tv_secs" to solve.
Quote:

*** TODO: Figure out the issue with 'tv_secs'.
*** __USE_OLD_TIMEVAL__ is used in a lot of Amiga projects I can see on GitHub. Look at https://wiki.amigaos.net/wiki/Programm ... _-_The_Data_Administrator and search for OLD_TIME - You can see that the Amiga is incompatible. Again, somewhere in the configuration I need to sort something out!
---> Okay, I noticed that at some point (2017-ish) struct timespec was added to CLIB2 include/time.h. I decided to keep the old clib2 as it was and just copy over that particular change to the time.h file. So, at this point we have solved the gethostname and the tv_secs issue. (Hack NUMBER -1)

Clearly, some version of something is incompatible. After that, I received an error about the usage of C99 type of for loop, this can be corrected. But, if the compiler is not C99 then surely coreutils was not built with 4.2.4!

So, I will hack in the pre c-99 change to the for loop in: lib/secure_getenv.c:87 (Hack always needed NUMBER 0)

Now we get the error:

To get around that, I just defined TZSET in or around 30 of time_rz. (Hack always needed NUMBER 1).

Then,
undefined referenced to some wide char function. This confirms that you really do need to link with libwide.a as specified in the readme file.

***Currently trying to add -lwide to the LIBS passed to ./configure.
So, this gets passed the error regarding strings, but the WIDE library relies on 'strnlen' which is not even included in the generated SDK version created via the X-compile tool chain build! This means that we have to update the version of the SDK/clib2 library since newer version include 'strnlen'.

*** So, we will no longer need hack NUMBER -1 since a newer clib2 will also include a definition for struct timespec (something that was added to clib2 also). AND SO, we end up going back to the fact of the bottom of README.os4 for CoreUtils which says: you need libwide and the "latest" clib2 version on github [although, the latest version at the time of that writing for 2017].

==So, let's use the latest clib2 - this may include compiling it===
NOTE: Even the latest clib2 from 53.34 (latest SDK) does not include strnlen. But, the git-hub master version does.

***TODO: Compile the latest clib2 from the git-hub master as referenced in the readme guide. Expect to fix NUMBER 0 and perhaps NUMBER 1 and then rebuild and see what happens. [[[DONE]]]

***** It is clear that this was never compiled with GCC 4.2.4 and since the wide library (libwide.a) uses strnlen it is also clear that we need the non-official clib2 included in even the latest SDK. clib2 on the github does include strnlen. Fact is, when you put the pieces together, I have realised that you need 1. a newer compiler with c99 and 2. the github version of CLIB2 3. yeah, libwide.a also.

So now: let's compile the latest CLIB2 (github), with the old 4.2.4 GCC compiler (we need to remove force aggressive loop option) and see what happens when we just drop the newly compiled CLIB2 into the older SDK location in /opt/ppc-amigaos. This will not result in not needing to do all of the hacks since, at the very least, we are using a non-c99 compiler!

===Compiling new Clib2 from GitHub===
This seemed to compile, but I am using the old 4.2.4 compiler which I should not! Anyway, it just compiled and I can see the libraries

***TODO: Put the built clib2 into the ppc-amigaos directory in chroot /opt/ppc* and see what the hell happens! I am only replacing the clib2 within the SDK directory, that may be an issue ... ? If that does not work, then put the latest SDK in there as well.

==> And so, this seems to have improved things. But there are more undefined references requiring the addition of "-lnet -lunix" so far. Also, using the latest clib2 resulted in me not needing to worry about non-C99 compliancy.

But this leads to: __huge_val being undefined. I think we are missing "-lm" also. So, let's try that...

===SUMMARY===
So, I finally got CoreUtils to compile. I wanted to do that because I noticed that with the latest CoreUtils.lha from OS4Depot RM -RF was not working. I would like someone else to confirm this though. So, if anyone can just create a directory and touch a file in that directory and then run RM -RF on that directory, can you confirm that this does not work. It was not for me; see also (https://github.com/adtools/coreutils/issues/1). What I wanted to do was to fix this issue. Since this required the source code I set about finding the CoreUtils source code and I found it on GitHub. At this point I was under the niave assumption that downloading the latest SDK would be enough, but I was quite wrong! During this experiment, I have realised that people are using a version of CLIB2 that is not within the latest SDK. I have also noticed that people are not using the version of GCC provided with the latest SDK; so, I ask myself, should I have known about this already? For someone new coming to the Amiga scene (niche, I know) would they know that the latest SDK is not really enough? If not, how would they know other than doing what I have done which is to ask on the forums? Further, the reason I want to fix CoreUtils for native usage on the AmigaOne is because I like to do everything on my Amiga. I have since heard that people are happy to develop for the Amiga using alternative machine and are happy to X-Compile. Maybe I am just insane, but I like the idea that if I only ever had one computer remaining after a nuclear apocolypse and it was my AmigaOne X1000: I would have the resources to develop to new software for it!

When I noticed that RM -RF was not working, I tried to just download CoreUtils and build it on my Amiga. But, the very use of RM -RF in the Makefile itself caused issues.

So, what did I do?
- I said, let's use my Linux system which already has the tools on it (albeit, a very slow machine)
- Downloaded CoreUtils from https://github.com/adtools/coreutils/
- Used the README.os4 in there and took inspiration from the last entry which said:
Quote:
- Realised that I would need a CrossCompiler to do this: I assumed that "adtools" was the main place. And I saw https://github.com/adtools/amigaos-cross-toolchain.
- Realised in the https://github.com/adtools/amigaos-cross-toolchain/ README.md says: you shall use a GCC 5.X compiler with 32-bit libs
- Decided to create a CHROOT on my Linux machine using Xenial 32 bit since that also came with GCC 5.x out of the box
- Built the ppc-amigaos-* tool chain and installed to the default /opt/ppc-amigaos
- The above point means that I have the default GCC 4.2.4 with an older version of the SDK which is purely from Hyperion.
- Then, I cloned the CoreUtils from the GitHub
- ./configure --host=ppc-amigaos
- Bumped into a number of issues along the way (see above)
- required -D__NO_NET_API
- required fixing C99 for-loops since the build process believed that this was a non-C99 compiler
- Realised that I really did need libwide.a as suggested in the README.os4 fle from the CoreUtils
- Realised that libwide was using 'strnlen' that was not even in CLIB2 using the latest SDK, and so:
- Realised that I needed to upgrade the CLIB2 version using the CLIB2 on the GitHub [https://github.com/adtools/clib2] (since the Hyperion official one did not have the necessary features)
- Compiled the latest CLIB2 from GitHub
- So, I kept the original /opt/ppc-amigaos/ etc files that were installed via the cross-compiler build above, but simply replaced SDK/CLIB2 with the newly compiled one
- Realised that I needed to use "-lnet -lunix -lm -lwide -lc"

- Finally compiled CoreUtils

===RESULT===
So, I SCP the freshly compiled RM to my Amiga X1000 and just try it out out of curiosity and it works! Now, my RM compiled will actually work correctly if there is something in a test directory.

=======

So, I am wondering if someone can test out RM using CoreUtils supplied through AmigaOS 4 Depot.

Regards.

===EDIT===
I may have just realised that the latest SDK does not need CoreUtils. Looks like the latest SDK has separate binary for RM, CP etc vs the older SDK (as of last week) which all went through the "coreutils" binary.

Question: Why does clib2/string.h in 53.34 not contain 'strnlen' whilst the version of clib2 on github does?

I get the feeling there is a breakaway / experimental scene going on here that forks off from the latest SDK and adds features not officially released.

The SDK provides 53.34 with GCC version 4.2.4, yet a lot of developers use at least version 8 now. Does the same sort of thing also apply to the SDK?

Okay, topic closed. Hopefully it will be useful for others in the same situation.

Basically, it all works fine now. I rebooted and it's running nicely.

Thanks for the help all!

@nbache
Can't argue with that, you are right. The point was really about my realisation of the APPDIR:.

At this point I cannot really see how it is useful, but after using this more I may very well change my opinion.

And, if I do not like it, I can just remove it from the path.

Okay, so I already have "1.23r5_beta07". I did not download it from your link above, but I then compared yours vs mine and there are no differences. I used a comparison tool. Of course, there were differences in bookmarks etc since yours is a clean install.

What I did not have were any enabled scripts. So, now I have:

- YouTube Fullscreen Fix (Your provided script)
- YouTube - EZ Download
- YoutTube HTML5 Converter

All of those are marked as enabled.

So, my current problems:

- If I just open "www.youtube.com" then I just get an unusable screen.
- If I firstly spoof as IPad 6.1 and then open "www,youtube.com" then I get a usable YouTube except that the video quality is still choppy. It is not that bad, but it is about 5-10 FPS. The audio is fine.

My Radeon drivers:


And the video card is the original one that came with the X1000s when they first came out. Basically a 4XXX / RV730.

Thanks for guiding me through this.

===UPDATE===

So I looked at George's video: AmigaOS 4.1 FE #3 - Using the Internet. So, it looks like you should not have to spoof anything. Problem is that when I explicitly enter "https://m.youtube.com" it always gets turned into the non mobile version, probably because it detects something in my setting that suggests it should use the desktop version.

I also see Emotion is possible to use for YouTube, so I can look into that also.

I get the feeling that spoofing to IPad 6.1 (which for me results in going to the mobile version) will do the same thing as what using m.youtube.com directly would do anyway.

@amigakit

Having trouble looking for the changelog. I am curious as to what changed.

Now I am expecting to be embarrassed that the changelog is right in front of me somewhere!

Thanks for the update.

@kas1e

Thanks for the info. And is @Walkero the youtuber? Who demonstrates with his X5000. I think he is Greek also...

Okay, so what you guys do is to get the latest SDK but just forget about the old compiler provided and use the new one you mentioned? Personally, I could not care less about C++, but I am wondering why you bother to use the newer C compiler. Of course using a newer compiler means what using a newer compiler always means: that clever people have improved it and better PPC code is generated etc... I am wondering if the real reason is for the ability to use C++.

I am not saying that using the newer compiler is bad! It makes total sense, and it probably helps ports newer software over to OS 4 and allows the C++ obsessed to be happy 😊.

Still, at some point, someone got that version of CoreUtils compiled with 4.2.4 I believe, and I cannot do it because I am metaphorically trying to drill a square peg into a round hole. That is, somewhere with my set up mentioned in the original post, I am not using the correct version of something or missing something in the initial configuration just before generating the Makefile.

I can hack my way passed the conflict of the gethostname function, but then I run into problems with general time/date structures. Like "struct timespec" not having a member "tv_secs".

So somewhere something is not fitting into the round hole and I guess it's either something I missed out in the configuration or a bad version of the SDK against the version of coreutils or something.

So why am I wanting to do it so badly? Because I am like all of you, an engineer, and it was done before.

And, why do I want to do this anyway? Because with the CoreUtils I have from os4 depot, RM -RF does not act as it should. If I have a directory and something inside it then even RM -RF will not work. I had to write my own RM program to get around it and I wanted to contribute by trying to fix it since I have done a bit of classic system development and have used the NDK 1.3 quite a lot. Yes, 1.3 - it's just a rule I have.

And, I could not just use delete because I needed rm since I was porting over a project with rm and different options to rm all over the Makefile. It makes porting an older POSIX project very difficult when RM is used almost all the time.

Great. I will try this all out.

I know I have posted quite a lot, but I am learning things about the AmigaOS 4 and I am really curious about what is happening.

Here is a classic example of what has been happening to me recently:

1. Try some cross compilation which inevitably is to build an executable built for my Amiga named "main"

2. SCP main to the Amiga's RAM Disk

3. Forget about the protection flags and run "main" in Shell

4. Get confused as to why when I do that a completely different program that I created called "main" gets executed!

So, since I am used to Linux it is quite a bewildering feature that the other MAIN program has a "symbolic link" in APPDIR: and since the AmigaOS does not see the actual "main" that I SCP'd as executable, it goes and runs the one that has a symbolic link created for it in APPDIR: since that is on the PATH.

I have to note that AmigaOS 4 is not Linux, but this is an.. interesting feature.

Hey all,

I use 1.23r5.

To get videos playing in YouTube I need to spoof as IPad 6.1 (I saw that off of some guide). The problem I have as that the video is quite choppy even at 360.

I have an X1000 using an R730 (Radeon 4XXX).

Trying to figure out if I am doing something wrong, or if it is the video card. Though, using my NAS I am play videos using my bought version of DvPlayer quite nicely (well, not 720p videos so much and not 1080p).

I have the latest Enhancer software and RadeonHD graphics driver (v3).

Any advice?

Thanks.

Hey both,

the reason for using GCC 4.2.4 is only because when I download the latest SDK version that is the version that is supplied. I know that a new SDK came out a few days ago, but this all started a week ago.

I assumed that was the version I needed to use. When reading the READMEs I was also getting pointed to 4.2.4.

The reason for compiling CoreUtils from source is purely for educational purposes.

I can also contact Olaf, but I am not sure if he still uses the email address that is referenced in the github page (GMX address).

==EDIT==

I also see with the latest sdk:

I meant to post this in OS4 Developer.

If a moderator can move it.

Thanks.

===TLDR added at end of this experience===
Go to post #10 for the final result of the particular use case: CoreUtils
Go to post #14 for the questions that I formed after this whole experience.

===Start of original post===
===Goal===
Cross compile and build CoreUtils on an x86 for use on my Amiga X1000 OS 4 FE U2.

===Some Info===
I will not post all commands in here, some obvious ones like copying directories I will ommit. The reason for posting all of this information is purely because of my own experiences: I hate it when searching for information and coming across a potentially great thread that does not contain enough information.

I also create this quasi-step-by-step guide because someone will probably go: NO! Don't do it like that! For example, I may be using an out-of-date guide or using a git-hub location that is way out of date, or, just doing something plain-wrong!

Lines that begin with "PRESUMPTION:" document my thought process and general questions.

===Host Machine===


===Host OS===


===Source Code for CoreUtils===
https://github.com/adtools/coreutils

===Guide(s) I am using for my goal===
I am really only using README.os4 / README and browsing the configure file to glean information.

===Start Doing Things===
I am going to create a CHROOT using Xenial 32-bit because we want to use 32-lib libraries and it comes with GCC version 5.X***; all the packages mentioned as requisites for compiling the cross tool chain match up with Xenial. I do not want to mess around with multi-arch etc and having a CHROOT seems a lot cleaner. It has been a long time since I did this, so there maybe easier or better methods.

*** - I mention this because I need to compile the cross-compiler toolchain, and the prerequisites mentions a need for GCC 5.X 32-bit.

===CHROOT a Xenial 32-bit===
I will create a directory: /var/2xenial32 which will be the root for the 32-bit Xenial.
I will use debootstrap to create a minimal image:


Copy the apt/sources and rename focal to xenial so that I can access the right repos for packages.

===Okay, now I need to get a cross compiler before building CoreUtils===
I will use: https://github.com/adtools/amigaos-cross-toolchain
And the guide for that: https://github.com/adtools/amigaos-cro ... ain/blob/master/README.md.

We will create the gcc 4.2.4 cross-compiler for OS 4 FE U2.

Let me CHROOT into the 2xenial32 and start building the cross toolchain. Before I can even start, let's get all the prerequisites in the README.md file. This is essentially running apt-get install for each of these packages. It also includes running install for a few other packages that are not mentioned in the README file that must have been left out by mistake; I needed to also install subversion and flex.

Also, during step 2 of the README.md:
./toolchain-ppc --prefix=/opt/ppc-amigaos build
the script (toolchain-ppc) will hang when trying to download http://isl.gforge.inria.fr/isl-0.12.2.tar.bz2 because this file no longer exists. So, I just searched for it and hacked in a new url.

Then, I run: ./toolchain-ppc --prefix=/opt/ppc-amigaos build
and wait for a long time, since the host machine is real slow!

And, when it is finished I test the default paths etc for the compiler:

And, to test with -mcrt=clib2:


And:

And, for -mcrt=clib2:


===Peforming a basic test of hello world===
As the heading suggest, I now create a simple application printing out hello world, scp to amiga and run it to ensure that it works so far.

Since the compiler defaults to newlib I compile helloWorld both by default and by appending -mcrt=clib2.

Both binaries work.

===Get back to building CoreUtils===
Since the README.os4 for CoreUtils says:

Quote:

I should probably get libwide and the "current" clib2 from the github. So, let's do that.

===libwide===
Just extract it into the SDK directory.

===clib2===
The issue is that for the documentation readme file for building http://github.com/adtools/clib2 says:
Quote:
So, I am not sure how to get the "netinclude".
Quote:

===start compiling CoreUtils===
Since the default for the X-compiler is not to use CLIB, I am assuming I need to override that and add CFLAGS=-mcrt=clib2 as well as set the --host=ppc-amigaos. The X-compiler needs to be on the path also!

Quote:

But, just to see what happens I try:

And this generates okay, but when I try

I get:


And, when you look at that line you can see:


So, as I already saw in the readme, we should be building with clib2!

Okay, so now I try (after cleaning out directory completely. Essentially, deleting it and copying a new one):

in this case, we get a Makefile again, but:

results in:

So, function 'gethostname' was already:

But in the core-utils directory that I am trying to build:

already exists.
Quote:

===Help===
So, I am just wondering if someone can help point me in the right direction.

Thanks all.

Thanks for the welcome all.

So, as I said, I completely resoldered a new coin cell holder. I checked voltage at the time of the existing battery and it was okay IIRC.

But, despite being a new coin cell holder, I did not go the full distance and just pop in a brand new battery.

Let me get a brand new battery anyway and see what happens since as you and I have already alluded to: X1000s do NOT like bad batteries!

So far we have the possibility of the radeon driver as also cited in the bug report which is not a 1-1 mapping of my issue but does have some similarities or an on-the-way-out battery.

It's a shame such an issue is not deterministically reproducible. Well, without waiting for what I guess is 24 hours and even then it is not 100% definite.

Thanks so far and I will report back.