OK, this is a strange one so figured I'd post it here since I know the Friedens read here more often anyway.
After I installed the new SDK, 53.15 for OS 4.1, on my OS 4.0 system, I rebooted to let the User-Startup changes take effect. However, it never finishes booting. I can see that it got an IP address from my router, and it did continue after that, but then it just stops dead and not even the Ctrl-Alt-Alt keypress will work any more.
Booted with no startup sequence and was able to fiddle around with User-Startup. Found out that it boots fine without the four lines the SDK installer added to User-Startup.
I saved those off in another file in S:, then tried running them after the system was up and booted properly. No hangs. I'm like "WTF!!?!?!?!"
Here are the lines that I moved out of USer-Startup into it's own file (I've named SDK-Start for now):
This really isn't making any sense to me. Anyone else have any idea why those lines make it hang if they are in User-Startup but not hang when they aren't in there?
Hmm.. is the OS4.1 SDK even supposed to work on OS4.0?
Good question. I only remember QuickFix releases that applied to SAM and OS4.1 A1; while the SDK installer seems to copy or make links to the shared objects contained in the QuickFixes.
It stops on the SDK: assign command. At least, that's the last line it shows. I suspect it's the execute line that's the problem.
I'm writing this in OWB, after removing the echo and SDK startup lines. I then re-ran the separate script with just the four lines from my original post, and it did not hang.
That's just odd. Running those four commands in User-Startup causes a hang, while running them separately after OS4 is finished booting does not result in a hang.
Hmm, only libstdc++.so, libssp.so, and libgcc.so match your checksums. The other two do not. I'll unpack the SDK installer again and check those files.
When I ran the SDK installer, there were some messages that popped up about something that was missing and some links (looked like an error from MakeLink?).
I'm just going to re-run the installer after I wipe out the SDK install I have and see what it does this time.
OK, after another install, it does the same thing. Hangs at the assign command, and only three of the new .so files are the same as listed above.
But, I did make note of where the errors happened during the install. It's just at the end of the Cairo files section, and shows the following errors in a shell window that pops up:
IF: Missing ELSE or ENDIF MAKELINK: object not found MAKELINK: object not found MAKELINK: object not found MAKELINK: object not found
Just to make sure of some things, I unpacked every lha archive in the SDK installer and compared the files. I don't see any .so files for the Cairo part anywhere in the unpacked files, comparing it against the package.xml file's contents. Maybe some files were accidentally left out of the archives?
The Installer tries to establish a link in the SDK directory to the original Cairo SOBJs in the systems SOBJs: assign, but these are NOT part of OS4.0! Or am I wrong? I think this SOBJs where introduced with OS4.1.
You are right, it's trying to make links from the SDK directory to the system SOs in SOBJS:. Thing is it has an If statement that is supposed to skip the makelink commands if the main cairo lib file is not there. One of the errors has to do with that If statement.
As it turns out, it works fine with OS 4.1. About an hour after I posted the previous message, I got my copy in the mail. It's installed and working beautifully. Plus the SDK installer went through without errors at all, as well as no hang after the reboot.
In any case, something isn't right with how it installs under OS 4.0 (including the July 07 update). I think those install errors have a lot to do with the way it acts after the reboot.
@ZeroG Although md5sum gets the job done, I think all my Amiga operating system files should have an Amiga version string. It would certainly be easier to read a version number than a long HEX string. Come on programmers, just add a little $VER ... to the Sobjs and make life a little easier for the user.
Yes, pleeeeeease! The SOBJs "version handling" is stone age and for an AmigaOS system inacceptable! I understand that there might be advantages for developers, the .elf subsystem, the porting whatsoever. Isn't there a place in the binary to put a little version into?