Issue with QT on X1000 [Solved]

Hi All,

At the moment on my X1000 I am struggling and somewhat frustrated with Qt, which is not working at all since the move from SFS to NTFS partitions (note I didn't use NTFS for the system partition - it is still running SFS as before).

More detail on what i did with the partitions is here on my blog if you need more detailed info:

http://amigax1000.blogspot.com.au/201 ... ith-sata-hd-on-x1000.html

I deleted Qt on the NTFS partition, commented out the Qt assign references in user-startup, rebooted and then reinstalled Qt on the system drive (SFS) which went ok, but no go to run any Qt apps. (and yes, I did put the dir SOBJS: >NIL line into the right place in user-startup..)

Qt Apps still say they can't find the lib#? .so objects they need, even though they are there (I checked the folder location) and referenced correctly as before, when it was working.

Btw I should also mention that the drive names changed for programs already installed when I moved everything to the new disks (from DH0: to HD0:, DH1: to HD2: in my case).

AmigaOS4 does not know about the changes to non-system disk files (as you would expect). I had already updated the relevant startup files to reflect the drive name change where needed prior to booting off the new disks for the first time. No errors on boot. (just to cover this off)

However in AmigaOS4.1 I note that it now uses a sys:prefs/env-archive/AppPaths folder to track any program locations across the various partitions when they are run. However, this only updates the location when an application is run. So I believed it is probably necessary to manually update each entry to reflect the new location, as the only other way is if you plan to run them all in turn to update the location. (Yes, I did this manual update last night including the Qt Apps referenced - took ages). Maybe there is another quicker way...but doing this had no effect on fixing Qt Apps though.

I am also curious if this app path information is used by AmiUpdate to work out what apps are installed to determine updates needed?

I am thinking about adding an assign in startup-sequence for DH0 to HD0, DH1 to HD2 to see if it cleans things up for Qt, which if it does would prove if something critical is still referencing to the old location. Since I reinstalled Qt from scratch using the new drive names, I can't imagine this would be affecting things, but you never know...

Please let me know if you have any other ideas on what else I can do to resolve this Qt issue? Appreciate any help.

Catcha,
Epsilon

I've had similar problems. I would get an error during system boot saying "can't add qt:/lib to sobjs:". I tried running the command manually "assign sobjs: qt:lib/ add", and would still get an error until the second or third time.
Even when the command succeeded, the path would not really add. I tried copying all the qt:lib/ into sobjs: but still ran into problems. I'll go back and trouble-shoot again when I've more time.

I forgot to mention that I'm using FFS partitions.
I've fixed the problem by waiting a couple of hours after OS4 has booted, then run the "assign sobjs: qt:lib/ add" and QT applications work fine.

@logicalheart

It depends on the order you have the assigns in user-startup

This works:

assign a: ram:
assign b: a:

This does not work:

assign b: a:
assign a: ram:

computers read scripts from top to bottom like we do.
you can't assign b: to a: before a: exists.

@all

I worked out the issue today, with some further help on why it happened from fellow Amiga user Sundown. Thanks as always for the help!

The issue was the libz.so.1 file in SOBJS: wasn't there. On further investigation it seems that it and a couple of the files in this folder (eg. libz.so.1.2) are links, rather than real files. As a result, when I copied all the files from one hd to another when changing my hard disks, the links were not copied across with it.

I copied the links from the original AmigaOS4.1.5 CD as suggested by Sundown and problem solved. Qt and all the apps work properly again.

Thought it was worth closing the loop on how I fixed this issue in case anyone else comes across it in the future when transferring their AmigaOS4 system partition to another drive.

Catcha,
Epsilon

@LiveForIt
This is after workbench has loaded, then I go into a shell and issue the command. It gives an error unless I wait a long time, so perhaps there is something running in NIL that hasn't finished.