Having set the QT_ACESSIBILITY to 1 properly, module now get's ignored by the KDE 4.9.5 environment as well as by any applications run by with the default kdeinit4 deamon started with 'starkde'. That is, the plasma-desktop etc. is inaccessible. Anything you run using the desktop file entry from the menu/with krunner is inaccessible. If you run your apps directly, that is from konsole, they are accessible. Even apps you run from the menu not using the desktop entry, by 'run command 'xxx'' are accessible as these are not launched with kdeinit4. Reproducible: Always Steps to Reproduce: Reproducing.: 1. Install qt-at-spi and dogtail/accerciser 2. Set the QT_ACCESSIBILITY=1 system-wide or session wide. (export in /etc/profile.d or /etc/kde/env or ~/.kde/env) 3. Log into KDE, run sniff or accerciser. See you can't see i.e. plasma-desktop. 4. Run any app from menu - it won't appear as accessible too. 5. Run any app from terminal directly - accessible. Now, if you restart plasma-desktop from terminal, it will be accessible too. Actual Results: If straight after launch, you run 'kdeinit4' command in terminal, the deamon get's restarted and all applications run with kdeinit4 afterwards are going to be accessible again. Thus likely the problem stands in how/what libraries are loaded during the original startup of kdeinit4 in startkde or why does it not load the qt-at-spi module as well. Also I can't be sure whether the qt-at-spi or kdeinit4 is where the problem lies, likely the latter.
I've done further poking into the /usr/bin/startkde and found that if the LD_BIND_NOW=true gets removed from the kdeinit4 startup line: LD_BIND_NOW=true /usr/libexec/kde4/start_kdeinit_wrapper +kcminit_startup -> /usr/libexec/kde4/start_kdeinit_wrapper +kcminit_startup everything works as expected. Looks like switching off the lazy binding and having symbols resolve at startup makes it to go without the libqspiaccessiblebridge.so for some reason. Also didn't find no difference with startup times, KDE seems even more responsive right after splash-screen, but that's unrelated.
Further on - this issue can be worked around by prelinking the qt-at-spi library prior running KDE. That is: $ prelink /usr/lib64/qt4/plugins/accessiblebridge/libqspiaccessiblebridge.so (Fedora) This will make the library bound to the kdeinit4 even with the LD_BIND_NOW set to true with the kdeinit4 initialization line (281 in starkde). Not sure why other libraries do get picked up, with prelinked not enabled or even installed at all, thus why it affects qt-at-spi module in particular. Did anyone have problems with qt-at-spi in some other distros than Fedora? We may put the prelink into the package install in Fedora, but would still be usefull to get to the core of this. Thoughts?
IMHO, startkde should not be mucking with LD settings that way, that LD_BIND_NOW hack should be removed.
Thanks for looking into this. I think this is a bug for the fedora bug tracker then, I don't think we can do anything about it (correct me if I'm wrong).
I guess the argument could be made to remove LD_BIND_NOW hack per comment #3 , but that's beyond the scope of just qt-at-spi