A little while ago, an updated port of the FUSE ZX Spectrum emulator was uploaded to OS4Depot. My first computer was a ZX Spectrum 48k, although I eventually ended up with a +3 model before I upgraded to my first Amiga. I was looking forward to getting this emulator installed so I could re-visit some of the classic 8-bit games I used to play; my favorite game is still Manic Miner although I never manage to get past the “Eugene’s Lair” level on my first attempt!
I hit a few stumbling blocks along the way though, so this “simple” exercise turned into a trip down the rabbit-hole which ended up teaching me a lot about my new X5000 system and AmigaOS 4. What follows is pretty much a blow-by-blow account of what I discovered along the way. As I’m still pretty new to OS4, I’m sure there’s probably a much neater solution to all this though, so any comments and feedback are all welcome!
Anyway, here’s the first problem I hit: I downloaded the ZIP archive for FUSE, unpacked it with UnArc and tried to launch it by double-clicking on the Icon. Instead of seeing the FUSE window appear, I instead got this error message:
I remember having this kind of issue all the time on my classic Amigas - a program would require some library that I didn’t have installed. Back in the day, if I was lucky I’d get an error message telling me what to download, or a note in a README guide somewhere. When that failed, I’d usually break out the fantastic and indispensable SnoopDOS utility to find out what a program was looking for. In this case however, it was clearly telling me what file I needed, but I had no idea where to install it. On my classic Amiga systems, standard Amiga libraries (with the
.library extension) simply got dropped in the
LIBS: volume, which was usually in the
Libs directory on your startup disk. But I had no idea what to do with ELF-format shared libraries.
Anyway, I searched on OS4Depot for “libpng”, and found this package. Looking at the contents of the archive, I could see this contained a
libpng16.so.16.34.0 file. This looked to be exactly what I was after! I downloaded the libpng archive, and unpacked it to a new directory in my Downloads folder (I really dislike archives that unpack into the current directory; it makes cleaning up and keeping track of where files came from so much harder). This left me with a bunch of library files and an
AutoInstall file. I looked at this, and it turned out to be a simple AmigaDOS script:
Delete SDK:Local/clib2/bin/libpng#? QUIET Delete SDK:Local/newlib/bin/libpng#? QUIET Delete SDK:Local/clib2/lib/pkgconfig/libpng#? QUIET Delete SDK:Local/newlib/lib/pkgconfig/libpng#? QUIET Delete SDK:Local/clib2/lib/libpng#? QUIET Delete SDK:Local/newlib/lib/libpng#? QUIET Delete SDK:Local/clib2/include/libpng#? ALL QUIET Delete SDK:Local/newlib/include/libpng#? ALL QUIET Delete SDK:Local/clib2/include/png.#? QUIET Delete SDK:Local/clib2/include/pngconf.#? QUIET Delete SDK:Local/clib2/include/pnglibconf.#? QUIET Delete SDK:Local/newlib/include/png.#? QUIET Delete SDK:Local/newlib/include/pngconf.#? QUIET Delete SDK:Local/newlib/include/pnglibconf.#? QUIET Copy Local/ ALL CLONE QUIET SDK:local/ CD SDK:local/newlib/lib MakeLink libpng.so libpng16.so.16.34.0 SOFT MakeLink libpng16.so.16 libpng16.so.16.34.0 SOFT MakeLink libpng16.so libpng16.so.16.34.0 SOFT
Fairly rudimentary, but it’s clear what it’s doing: It first deletes any existing libpng-related files, and then copies things to the required locations, and sets up some symbolic links in
SDK:local/newlib/lib. If you’re familiar with how Unix systems handle shared libraries, this should look pretty similar. I also discovered from that script that AmigaDOS can make use of symbolic links - I’m not sure when support for that was added, but I don’t recall it being around on my classic Amigas.
Only problem was, I didn’t have any
SDK: assign, or any directory structure resembling the archive on my system. After some searching online, it appears this is created by the official SDK for AmigaOS 4, which can be downloaded from the Hyperion website. I picked the most recent version, SDK_53.30.lha (Software Development Kit for AmigaOS 4.1 Final Edition) and downloaded it.
After I’d unpacked it, I ran through the supplied installation utility, only changing the location to my standard
Software: assign. I selected a “Full Install”, as this bundles a lot of very useful-looking GNU tools and utilities, as well as include files and compilers:
Definitely a lot to go exploring through on another occasion! I noticed that it had also modified my
S:User-Startup file to make sure the
SDK: assign is created, and it also dropped in another startup file that is run on boot:
;BEGIN AmigaOS 4.1 SDK assign SDK: Software:SDK execute SDK:S/sdk-startup ;END AmigaOS 4.1 SDK
SDK:S/sdk-startup, it appears that this sets up assigns and other things that are needed for the bundled compilers and utilities. In any case, I now had my
SDK: assign, so I could go back to my libpng download directory and run
execute AutoInstall from an AmigaDOS shell. This completed, and I could then see that the libpng files were copied to the correct destination under my SDK root. So, I clicked on the FUSE icon again, and…. same error: “Failed to load shared object libpng16.so.16.34.0”. Damn.
At this point, I discovered there was a
SOBJS: assign which appeared to point to the
System:Sobjs directory which also seemed to be full of
.so library files. I decided to try and copy the libpng library there:
copy SDK:local/newlib/lib/libpng16.so.16.34.0 system:SObjs/
And I then re-launched Fuse. Now, I saw a different error - this time, complaining about not being able to find
libz.so.1. One step forward, two steps back…. This
libz.so.1 file however was in the
SDK:local/newlib/lib directory, but I decided against copying everything in there over as it seemed pretty hacky, and a sure-fire way to screw something up. Plus, it seemed that there must be a way of adding this SDK lib directory to the system-wide library search path.
Now, on Linux or Unix systems, I’d have looked for a way to either re-compile Fuse with the correct
-R flags, or found a way of adding the SDK to the
LD_LIBRARY_PATH variable. In this case though, I was totally stuck and in a very unfamiliar place. I shelved my “get FUSE installed” project for the time being, and instead took a brief diversion into getting QT installed. Quite by chance, I noticed that it added something very interesting to the end of my
;BEGIN Qt-4.7 assign Qt: "Software:Programs/Qt-4.7" path Qt:bin ADD assign sobjs: Qt:lib ADD ;END Qt-4.7
Whoah. It looked like it was appending a path onto an existing Assign - I had no idea that AmigaDOS supported this! I’ve used the
ADD syntax to the
path command many times when adding additional directories full of tools, but never thought to try it with an Assign. It looks like it was added into AmigaDOS release 2, so it’s always been available to me ever since I got my first A600. Another new thing I learned!
So, I then added the following to the end of my
; Needed for FUSE etc to pick up on new libraries assign Sobjs: SDK:local/newlib/lib ADD
I rebooted, clicked on the Fuse icon, and…..(cue drum-roll)
Success! Although, I have to admit that at this point, I lost around 2-3 hours downloading and playing tons of classic games from the World Of Spectrum archives :)
However, this little distraction did teach me some new things:
- AmigaDOS supports both hard and soft symbolic links.
Assigncan take an
ADDparameter which appends directories onto a logical assign.
SOBJS:assign appears to be where programs look for ELF-format shared libraries on startup.
- The OS4 SDK contains some very useful CLI tools and is worth installing on any Amiga OS 4 system even if you don’t intend to develop software with it.
- Even after 30-odd years, there’s still something new for me to learn about classic AmigaDOS commands!
Finally, I’d just like to note that shortly after I solved the FUSE problem, someone very helpfully posted a comment which highlights an alternative fix - simply copying the libpng library to the FUSE directory. Although I wish I had thought of trying that, this little diversion proved to be a very useful exercise and I’m glad I got to dig a little deeper “under the hood” of my new X5000.