I downloaded this a while ago. As my SDK over the years had become a bit of a mess with additions and beta files I thought it would be best to get something that should work straight out of the box with the latest OS4 update 2.
However evertime I try to compile somethying I get the following message:
smf wrote: For one user the message could appear random when using the amiga shell (no error message when using the sh shell)
For another one it could happen when compiling sources from the ram disk:
We may be getting somewhere.
I always do compile from files copied to the ram: disk. It avoids overwriting things by accident. However, doing it that way always worked in the past, it is just with the newest SDK I get a problem.
SH, I am not really sure what this is and why I would use it in place of the Amiga console ? OK I tried typing sh into a 'real' concole and got an interface with a \
It did not like me typing ram: to get to the required directory so I now do that first and then enter sh.
Now I do get some normal output when running gcc ro make. As I expected it was full of errors as my SDK as yet has no third party includes, it is still pristine. So anything needing those includes gives an error - no problem that can be fixed.
The thing is why would I need to use SH, I never had to before. Just doing everything from the normal shell worked fine.
The thing is why would I need to use SH, I never had to before. Just doing everything from the normal shell worked fine.
Who told you that you need to use sh? This is a UNIX shell that can be used in situations where you try to port some software to AmigaOS 4 and you need a Bourne Shell (https://en.wikipedia.org/wiki/Bourne_shell) compatible terminal. This is useful, for example, when you want to use ./configure.
If you use sh, the paths are all like on UNIX, i.e. /ram/T
@nbache Thank you, Niels. Somehow I missed that comment.
The thing is that 53.34 changes against the 53.30 are minor, especially with the gcc compiler and the binaries around it, which are exactly the same.
The purpose of SDK 53.34 was to gather all the updates that came as part of the two system updates and have all of them into one package, so as to be easier for the users to have an up-to-date SDK.
Maybe a good test would be to make a new installation of 53.30 and test it again, and see if you get the same issue with that.
Maybe a good test would be to make a new installation of 53.30 and test it again, and see if you get the same issue with that.
No need to reinstall it, it was already there in a directory called old_sdk, so all I needed do was rename the folders to sdk_new and sdk and reboot.
The new install of v53.34 was a red herring, I still get the same problem when compiling from ram:. It seems OK if compiling from an HD partition. I had not used the SDK recently until installing the new one so it looks as if the problem was already there. Maybe something has changed in the ram handler that GCC does not like ?
The space in the name "RAM Disk" does not seem to be it, I renamed it to one word before trying a compile and still get the same error if compiling from Ram: (RAMDisk:).
I am using a fairly pristine OS4.1FE update 2 with Enhancer 2.2, but without some of the command replacements. I'll try some older boot partitions to see if they make any difference.
@BillE Thank you for checking this out. To be honest, I have never tried to compile on ram. I will try it with my current setup and see how it works, and if I can find any solution.
Just tried with the latest SDK and gcc 11.3...no such error
@BillE
You said you reinstalled your SDK...did you maybe forget to change any assigns (you maybe altered with your old SDK?) Check user-startup, maybe there are some residues left behind that interferes with the new installation.
Interestingly, the last two methods work fine. So it seems as long as the shell is not set to the RAM: directory compiling from ram: using full paths works from other directories.
Weird.
This seems to be narrowing down my problem to running the shell with RAM: as its default.
I am still set to 53.30 but will go back to 53.34 as I am now sure that the version of the SDK is not the problem, I only noticed it after upgrading.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
