Bug 1111

Although the two bug reports (178 and this one) might not be related, the common failures seem more than a coincidence. I suspect something awry with the builtin libisofs.

k3b also is packaged with libisofs 0.2. As the libisofs directories in tdelibs and k3b are more or less the same, seems that something else common to building libisofs 0.2 might be the cause of the bugs.

That the k3b failure does not occur in 3.5.10 indicates a regression somewhere in Trinity.

The problem is unlikely to be mkisofs because the same ISO images are readable in k3b 3.5.10.

I have more information.

The problem seems limited to 32-bit systems, although I don't have conclusive data. I do not have this problem with Slackware 14.0 64-bit where K3B recognizes DVD ISO images just fine.

I'm guessing the problem is a long versus long long variable type or something similar. We ran into a similar problem with the kio-iso slave in bug report 178, although that bug report is not yet resolved.

I'm certain this bug report is related to bug report 178 and the problem lies within the common libisofs of both kio-iso and k3b.

The problem is limited to 32-bit systems. Both kio-iso and k3b recognize DVD ISO images without fail in a 64-bit system but not within a 32-bit system.

I'm still guessing the problem is an int/long versus long long variable type declaration or something similar.

Created attachment 822 [details]
Partial patch to read large file sizes

This patch is patterned after the same patch commited in bug report 178. Like the patch in bug report 178, this patch does not completely resolve the problem.

Comment on attachment 822 [details]
Partial patch to read large file sizes

Pushed to GIT in hash 8ade4e2.

Can anyone on a distribution other than Slackware confirm that 32 bit builds exhibit the issues Darrell is indicating?  For instance, I cannot make TDE on Ubuntu fail, indicating that the problem may be distribution specific.

Thanks!

As mentioned in related Bug 178, this failure seems to be distribution specific. 

Additionally, as the underlying libisofs code is duplicated between k3b and the ISO kioslave, both reports have been combined into this one report.

In my 32-bit build log output I notice the following:

checking size of long... 4
checking size of char *... 4
checking size of size_t... 4
checking size of unsigned long... 4

In my 64-bit log:

checking size of long... 8
checking size of char *... 8
checking size of size_t... 8
checking size of unsigned long... 8

Is there a way to control those sizes?

When I use the terms 32-bit and 64-bit I am referring to the build environment and not my hardware. All builds are performed on the same AMD 64-bit dual core CPU system.

From 32-bit Ubuntu Precise build log:

checking size of int... 4
checking size of short... 2
checking size of long... 4
checking size of char *... 4
checking size of size_t... 4
checking size of unsigned long... 4
checking sizeof size_t == sizeof unsigned long... yes
.
.
checking for stat64... yes

Sizes are the same.
You also have stat64 on 32-bit?

More info:

K3B in 3.5.10 reads DVD ISO images without failures. 3.5.10 does not have kio_iso installed.

Build Log:

checking for stat64... yes

(In reply to comment #8)
> Is there a way to control those sizes?

No, they are set by gcc (which in turn bases them on the exact hardware being targeted) and reported for informational purposes only.

(In reply to comment #9)
> You also have stat64 on 32-bit?

This is a good catch and it got me thinking whether or not Ubuntu might have hacked up the "normal" open/stat calls to work in 64-bit mode on a 32-bit system.

Darrell, can you please try this in the tdelibs ISO kioslave:
In isofs.c, on line 815 change 'open' to 'open64'

Recompile, reinstall, and see if anything has changed.

Thanks!

Tim

> This is a good catch and it got me thinking whether or not Ubuntu might have
> hacked up the "normal" open/stat calls to work in 64-bit mode on a 32-bit system.

I recall reading that some Debian/Ubuntu 32-bit systems come with a special 64-bit kernel. Would that make a difference?

I found a 3.5.10 compatible version of krusader, which includes the kio_iso slave. Like the 3.5.10 k3b, the kio_iso slave had no problem with DVD ISOs, indicating something different with Trinity.

Next, as shot in the dark based on browsing the krusader source files, I rebuilt Trinity k3b, adding the D_LARGEFILE64_SOURCE flag:

CFLAGS="$CPUOPT -D_LARGEFILE64_SOURCE" \
CXXFLAGS="$CPUOPT -D_LARGEFILE64_SOURCE" \
./configure \
...
...

No change.

Next I applied the following patch and rebuilt Trinity tdelibs:

diff -urN tdelibs/kioslave/iso/libisofs/isofs.c tdelibs.new/kioslave/iso/libisofs/isofs.c
--- tdelibs/kioslave/iso/libisofs/isofs.c 2012-09-14 18:00:19.000000000 -0500
+++ tdelibs.new/kioslave/iso/libisofs/isofs.c 2012-09-25 20:38:52.000000000 -0500
@@ -812,7 +812,7 @@
    sector=atoi(argv[2]);
    printf("Using starting sector number %d\n",sector);
  }
- fd=open(argv[1],O_RDONLY);
+ fd=open64(argv[1],O_RDONLY);
  if (fd<0) {
    fprintf(stderr,"open error\n");
    return -1;

No change.

Puzzling to me is why both kio_iso and k3b work in 32-bit 3.5.10 and not in 32-bit Trinity.

Here are my build script configure options for k3b:

CFLAGS=$CPUOPT \
CXXFLAGS=$CPUOPT \
./configure \
  --prefix=${PREFIX} \
  --sysconfdir=${SYSCONFDIR} \
  --libdir=${LIBDIR} \
  --mandir=${MANDIR} \
  --docdir=/usr/doc \
  --with-qt-dir=${QTDIR} \
  --with-qt-includes=${QT_INCLUDE_DIR} \
  --with-qt-libraries=${QT_LIB_DIR} \
  --disable-rpath \
  --without-cdrecord-suid-root \
  --enable-ffmpeg-all-codecs \
  $DEBUG_AUTOTOOL_OPT || exit 1

Where:

ARCH: i486
TARGET: i486
CPUOPT: -O2 -march=i486 -mtune=i686

Another anomaly: I have a 32-bit virtual machine with Trinity installed. I have not used that system in several weeks. I have Trinity GIT short version 7888 installed. All packages were built Aug. 30 using the same build environment I always use. In that virtual machine, kio_iso reads DVD ISO images but k3b does not.

(In reply to comment #14)
> Another anomaly: I have a 32-bit virtual machine with Trinity installed. I have
> not used that system in several weeks. I have Trinity GIT short version 7888
> installed. All packages were built Aug. 30 using the same build environment I
> always use. In that virtual machine, kio_iso reads DVD ISO images but k3b does
> not.

This makes sense, as the k3b patch was not pushed until very recently.

Tim

<snip>
> Puzzling to me is why both kio_iso and k3b work in 32-bit 3.5.10 and not in
> 32-bit Trinity.

What does a 'diff -ur old_3510_source/libisofs new_tde_source/libisofs' show?  For this to work at all, those 3.5.10 sources would have needed to be patched for files >2GB, and I would like to know what is different between their version and the TDE version.

Thanks!

Tim

I've compared the libisofs sources several times. Nothing there.

The original 3.5.10 packages I am using have no patches related to this story. The 3.5.10 sources I have are patched very little anywhere.

(In reply to comment #17)
> I've compared the libisofs sources several times. Nothing there.
> 
> The original 3.5.10 packages I am using have no patches related to this story.
> The 3.5.10 sources I have are patched very little anywhere.

The original sources don't use "long long", therefore they should be completely broken with files >2GB on 32-bit.

The fact that you can read the images successfully on your virtual machine is curious.  Are you using an identical kernel version, base system library versions, etc. on that virtual machine as compared to your other testing machine?

> The original sources don't use "long long", therefore they should be completely
> broken with files >2GB on 32-bit.

One would think they should fail --- yet they don't....

> The fact that you can read the images successfully on your virtual machine is
> curious.  Are you using an identical kernel version, base system library
> versions, etc. on that virtual machine as compared to your other testing
> machine?

The tests are not perfect like-for-like. My every day system is 32-bit Slackware 13.1 (gcc 4.4.4). The 3.5.10 environment uses a 2.6.27.x kernel, gcc-4.2.4. I am building Trinity packages for Slackware 14.0, both 32-bit and 64-bit, for testing purposes. With that said, this morning I booted into 32-bit Slackware 14.0, which uses the same 3.2.29 kernel, gcc 4.7.1, etc. as the 64-bit version. Both kio_iso and k3b work without errors in Slackware 14.0 64-bit, but I saw the same errors in the Slackware 14.0 32-bit as I do in my every day 13.1 32-bit system. So nothing (obviously) conclusive there.

I do have a set of KDE 3.5.10 packages I created long ago for 32-bit Slackware 13.1. I hope to create a temporary virtual machine and test those packages. That at least would provide a like-for-like with my every day 13.1 32-bit system.

I have some 3.5.13 packages for 13.1 32-bit which I hope to test.

Today I rebuilt krusader (Trinity) today with the --with-kioiso configure option. I did this with the slim hope that the original krusader kio_iso support might work, but no change in the results. At this point I'm leaning toward something fundamental in tdelibs. Somewhere/somehow large file support is not being built correctly in my 32-bit systems. Hopefully I'll know more after testing in the temporary virtual machines.

In tdelibs/CMakeLists.txt is -D_LARGEFILE64_SOURCE=1. This should force a build with large file support. After building tdelibs in build log is everything okay? Nothing suspicious, what would concern to large file support?

Interesting. When I grep the tdelibs sources, I find this:

tdelibs/kioslave/file/CMakeLists.txt:13:  -D_LARGEFILE64_SOURCE
tdelibs/kioslave/file/Makefile.am:3:AM_CPPFLAGS = -D_LARGEFILE64_SOURCE

tdelibs/kio/misc/CMakeLists.txt:21:  -D_LARGEFILE64_SOURCE
tdelibs/kio/misc/Makefile.am:19:AM_CPPFLAGS = -D_LARGEFILE64_SOURCE

tdelibs/kio/CMakeLists.txt:13:  -D_LARGEFILE64_SOURCE=1
tdelibs/kio/Makefile.am:19:AM_CPPFLAGS = -D_LARGEFILE64_SOURCE

tdelibs/kio/kio/Makefile.am:19:AM_CPPFLAGS = -D_LARGEFILE64_SOURCE

Only one of the three CMakeLists.txt files above have -D_LARGEFILE64_SOURCE=1. The other two have only -D_LARGEFILE64_SOURCE. I don't know whether than makes any difference. My tdelibs build log is filled with "-D_LARGEFILE64_SOURCE=1." Therefore I doubt the other two CMakeLists.txt files make a difference.

However, curious that tdelibs/kio/kio/CMakeLists.txt does not contain the definition while the Makefile.am does.

Oh, I'm sorry, to find I was already in another folder. :(
In kdelibs I got it as well as those you mention.

I tried the following patch to no avail:

diff -urN tdelibs/kio/kio/CMakeLists.txt tdelibs.new/kio/kio/CMakeLists.txt
--- tdelibs/kio/kio/CMakeLists.txt	2012-09-14 18:00:16.000000000 -0500
+++ tdelibs.new/kio/kio/CMakeLists.txt	2012-09-26 15:48:40.000000000 -0500
@@ -28,6 +28,10 @@
   ${GAMIN_INCLUDEDIR}
 )

+add_definitions(
+  -D_LARGEFILE64_SOURCE=1
+)
+
 link_directories(
   ${GAMIN_LIBDIR}
 )
diff -urN tdelibs/kio/misc/CMakeLists.txt tdelibs.new/kio/misc/CMakeLists.txt
--- tdelibs/kio/misc/CMakeLists.txt	2012-09-14 18:00:18.000000000 -0500
+++ tdelibs.new/kio/misc/CMakeLists.txt	2012-09-26 15:47:54.000000000 -0500
@@ -18,7 +18,7 @@
 add_subdirectory( kntlm )

 add_definitions(
-  -D_LARGEFILE64_SOURCE
+  -D_LARGEFILE64_SOURCE=1
 )

 include_directories(
diff -urN tdelibs/kioslave/file/CMakeLists.txt tdelibs.new/kioslave/file/CMakeLists.txt
--- tdelibs/kioslave/file/CMakeLists.txt	2012-09-14 18:00:18.000000000 -0500
+++ tdelibs.new/kioslave/file/CMakeLists.txt	2012-09-26 15:48:12.000000000 -0500
@@ -10,7 +10,7 @@
 #################################################

 add_definitions(
-  -D_LARGEFILE64_SOURCE
+  -D_LARGEFILE64_SOURCE=1
 )

 include_directories(

I ran two experiments with interesting results.

1. I installed 3.5.10 packages I built for Slackware 13.1 32-bit. I built and installed krusader as well, because that package had the original kio_iso service. Both k3b and kio_iso correctly detected DVD ISO images.

2. I installed 3.5.13 packages (not 3.5.13.1) I built for Slackware 13.1 32-bit. Both k3b and kio_iso correctly detected DVD ISO images.

As the original problem report with both k3b and kio_iso were from me, using Slackware 13.1 32-bit, I believe these two tests provide reasonable evidence the problem is not Slackware or Slackware 13.1 32-bit.

As noted in a previous comment, the 3.5.10 packages are not patched in any way as recently done with both k3b and kio_iso in GIT. The 3.5.13 packages were not patched either.

Seems then the cause is either Trinity GIT or that I am doing something differently in my build process from when I built the 3.5.10 and 3.5.13 packages long ago. Not to forget that the problem does not arise in 32-bit Debian based systems. Unfortunately, people using other distros have not contributed to this conversation and thus, leaves the question of distros unresolved at this time.

When the 3.5.13.1 tarballs are available I will try to build a package set and test there too. If the problem returns we then would have a clue that one of the backported patches might be part of the problem. If the problem does not arise then that leaves my build process or a patch not backported to 3.5.13.1.

With that said, any idea which patches along the way since 3.5.13 might --- might --- cause these failures with reading large files? I could test by reversing those possible patches.

By the way, the 3.5.10 and 3.5.13 tests were conducted in different virtual machines. There was no possible contamination from one to another.

Was CMake or Autotools used to compile the 3.5.13 packages?

Whatever was in place at the time --- some were cmake and some were autotools. I remember at that time, some of the cmake converted packages did not build well and we continued to use autotools for some packages.

Looking at my backups at the time 3.5.13 was released and the date stamp of Nov. 19 for the 13.1 packages, I probably built kdelibs and kdebase with cmake, but my build script during that period allowed me to build with both, which we needed to help debug the cmake conversions. I can't tell for certain which system I used to create the 3.5.13 packages, but I'm guessing cmake because that is what we were trying to push at the time and cmake was the first/preferred choice in my build script.

k3b was and still is autotools.

(Odpověď na komentář #24)
> 2. I installed 3.5.13 packages (not 3.5.13.1) I built for Slackware 13.1
> 32-bit. Both k3b and kio_iso correctly detected DVD ISO images.
> 
> As the original problem report with both k3b and kio_iso were from me, using
> Slackware 13.1 32-bit, I believe these two tests provide reasonable evidence
> the problem is not Slackware or Slackware 13.1 32-bit.
> 

This could confirm the observation that on 3.5.13.1 I not noticed this problem.

> 
> When the 3.5.13.1 tarballs are available I will try to build a package set and
> test there too. If the problem returns we then would have a clue that one of
> the backported patches might be part of the problem. If the problem does not
> arise then that leaves my build process or a patch not backported to 3.5.13.1.
> 

There are tarballs marked as 3.5.13.1~rc1:
http://ppa.quickbuild.pearsoncomputing.net/trinity/releases/3.5.13.1/

I have several data DVDs that provide possible clues about when the failures probably started. I likely used k3b to burn those disks, although I don't yet have evidence (I need to learn how to query a disk's meta data).

The oldest file date stamp is March 27. The newest is July 15. The remaining DVDs have file date stamps of April 11.

I tested three previous GIT package sets in a virtual machine. Thus far, kio_iso works with all three sets whereas k3b does not. The oldest set was created about the week of July 7. I'll look at the patches committed between March 27 and July 15 as well as backups of my build scripts during that period. I'm browsing my backups to see whether I have other GIT package sets I could test.

Curious is that I installed my current GIT packages in a Slackware 13.1 32-bit virtual machine and kio_iso works there. The only difference between that system and my regular 13.1 system is the kernel. The virtual machine uses 2.6.33.4 whereas my regular system uses 2.6.33.15. Could that difference play a role?

The only other difference I can conceive at the moment is the video driver. The virtual machine uses the VirtualBox drivers and the main machine uses the proprietary nvidia drivers.

I tried a new profile to no avail. The fact that kio_iso works in the virtual machine indicates something awry on my main system with respect to kio_iso.

I can't get k3b to recognize DVD ISO images with any GIT package set I have tried thus far.

At this point I'm inclined to think the two problems might not be related.

In my backups I found a GIT package set from about March 17. k3b works there. The krusader package unfortunately does not have the kio_iso service built in and I could not test that because the service had not yet been enabled in tdelibs (May 6). Nonetheless, that k3b works indicates something changed along the way. Would seem then that looking at commits between ~ March 17 and ~ July 7 might help.

Is there a way to revert my entire local GIT tree to a specific date?

Can you attach an strace of the failing isoslave from the latest TDE GIT version you have already built?  You can do this with this command:
strace konqueror iso://path/to/mybadiso.iso &> strace.log

This debug output will help to determine exactly which system call, if any, is failing and why.

Thanks!

Created attachment 830 [details]
Strace where kio_iso failed

Created attachment 831 [details]
strace where kio_iso succeeded

I attached two strace logs. One where kio_iso failed and one where kio_iso succeeded.

Notes:

The strace for the read failure is 50% larger than the successful read.

The significant differences in the strace logs seem to start at about lines 12230. The failed strace is doing a lot more than the successful trace.

The tests were performed as root to eliminate potential file permission problems.

Same Slackware 13.1 32-bit system. There are minor differences between the two systems. I'm trying to isolate how those differences might be affecting the outcome.

k3b does not recognize DVD ISO images in either system. k3b displays the "No image file selected" message in both systems.

The references to /usr/local/tde-mods is where I store $TDEDIRS files that override the $TDEDIR default files.

I redirect $TMP, $TMPDIR to tmpfs, which on my system is /dev/shm.

I have tested with fresh profiles with the same results.

Unfortunately the kioslave strace did not show up in your logs, which is something I was kind of expecting.  Therefore, the procedure just got more complicated. :-)

In order to debug a kioslave, you need to follow the instructions in this document:
http://git.trinitydesktop.org/cgit/tdebase/tree/kioslave/DEBUG.howto

In your case, that looks like this:
TDE_SLAVE_DEBUG_WAIT=iso tdeinit
<get the pid from the tdeinit output>
strace -p <pid> &> strace.log
kill -SIGCONT <pid>

Do that on the system that works and also the system that fails, then post both logs here.

Thanks!

Tim

This stuff makes my head hurt.

I have a fresh clue that I believe is important. I figured out the difference between the failed and successful systems.

On the system that successfully allowed kio_iso to work, the connection was through an NFS share.

I just validated this on my main system, whre all previous attempts to use kio_iso was through locally mounted partitions. On that system when I connected to an ISO image through an NFS share, kio_iso succeeded in viewing the image.

I tested the converse too. I tested a locally stored ISO image on the system that kio_iso was working and once again, kio_iso failed to view the image.

I have not performed any testing through samba shares. Regardless, interesting that kio_iso succeeds through NFS and not local mounts. I'm also curious why Debian systems do not exhibit the problem. That does not mean Slackware systems are doing things differently --- the problem could very well be how I configure things.

Bear in mind that the behavior I'm seeing with kio_iso is not helping with resolving k3b. k3b refuses to recognize DVD ISO images regardless of whether the location is an NFS share or local mount.

I hope this helps.

(In reply to comment #36)
> This stuff makes my head hurt.
> 
> I have a fresh clue that I believe is important. I figured out the difference
> between the failed and successful systems.
> 
> On the system that successfully allowed kio_iso to work, the connection was
> through an NFS share.

Interesting!  All of my test systems run on NFS so that they can be quickly reimaged, among other things, and this may very well have masked the problem.  I'll do some tests here to see what shows up.

I was wondering whether you past tests were through NFS shares. Possibly then Debian systems have the same problem with local mounts?

(Odpověď na komentář #38)
> I was wondering whether you past tests were through NFS shares. Possibly then
> Debian systems have the same problem with local mounts?

With 3.5.13.1 on Squeeze I always tested on local mounts (ext3).

> In your case, that looks like this:
> TDE_SLAVE_DEBUG_WAIT=iso tdeinit
> <get the pid from the tdeinit output>
> strace -p <pid> &> strace.log
> kill -SIGCONT <pid>

Um, I'm not following how to grab the PID. What tdeinit output? My ps output:

 3233 ?        S      0:01 dcopserver [tdeinit] --nosid --suicide
 3237 ?        S      0:09 kded [tdeinit] --new-startup
 3259 tty1     S      0:00 /opt/trinity/bin/tdeinit_phase1
 3262 ?        S      0:00 ksmserver [tdeinit] --windowmanager twin
 3264 ?        S      0:21 twin [tdeinit]
 3270 ?        S      1:09 kicker [tdeinit]
 3311 ?        S      0:01 kaccess [tdeinit]
 3316 ?        S      0:01 knotify [tdeinit]
 3319 ?        S      0:03 klipper [tdeinit]
 3324 ?        S      1:28 kmix [tdeinit] -caption KMix -icon kmix -miniicon kmix
 5482 ?        S      0:01 kio_uiserver [tdeinit]
 5637 ?        S      0:53 konsole [tdeinit] --tn xterm
25065 ?        S      1:11 konqueror [tdeinit] --silent
31270 ?        S      3:11 kate [tdeinit] --use

(In reply to comment #39)
> (Odpověď na komentář #38)
> > I was wondering whether you past tests were through NFS shares. Possibly then
> > Debian systems have the same problem with local mounts?
> 
> With 3.5.13.1 on Squeeze I always tested on local mounts (ext3).

I can confirm the bug exists on local mounts on Ubuntu and have traced the bug into TQt3 itself (TQFil::open() fails).

(In reply to comment #41)
> (In reply to comment #39)
> > (Odpověď na komentář #38)
> > > I was wondering whether you past tests were through NFS shares. Possibly then
> > > Debian systems have the same problem with local mounts?
> > 
> > With 3.5.13.1 on Squeeze I always tested on local mounts (ext3).
> 
> I can confirm the bug exists on local mounts on Ubuntu and have traced the bug
> into TQt3 itself (TQFil::open() fails).

I think I found the root of the problem in the TQt3 build log:
"Large File support .. no"

The question now is why is TQt3 not detecting large file support?

(In reply to comment #42)
> (In reply to comment #41)
> > (In reply to comment #39)
> > > (Odpověď na komentář #38)
> > > > I was wondering whether you past tests were through NFS shares. Possibly then
> > > > Debian systems have the same problem with local mounts?
> > > 
> > > With 3.5.13.1 on Squeeze I always tested on local mounts (ext3).
> > 
> > I can confirm the bug exists on local mounts on Ubuntu and have traced the bug
> > into TQt3 itself (TQFil::open() fails).
> 
> I think I found the root of the problem in the TQt3 build log:
> "Large File support .. no"
> 
> The question now is why is TQt3 not detecting large file support?

It turns out that tqmake-dependent compile-time checks were silently failing, resulting in large file support being disabled.  This has been fixed in GIT hash 5feb80c; recompiling and reinstalling TQt3 from GIT should resolve this issue.

*** Bug 178 has been marked as a duplicate of this bug. ***

Ah, so the pieces of the puzzle fall together. Looks like commit 1ecf57d would be the breaking point, from bug report 843, where some of the TQt3 bin files were renamed. That patch was from 2012-06-19. The date of this bug report (2012-07-16), discussions in bug report 178 (2012-06-29) and 465 (2012-06-29) all coincide with the commit date.

Explains why the old package set from March works, why 3.5.10 works, and why Slavek did not see the problem --- commit 1ecf57d is not back ported to 3.5.13.1. Anybody who built against Qt3 would not see the problem either. Both NFS and 64-bit builds masked the problem.

I haven't yet completed a full build run, but kio_iso and k3b both now recognize DVD ISO images from local mounts.

Before we consider closing this bug report, I would like to test with the related patches reversed. Those patches were not needed prior to commit 1ecf57d and were never needed in 3.5.10.

(In reply to comment #45)
> Before we consider closing this bug report, I would like to test with the
> related patches reversed. Those patches were not needed prior to commit 1ecf57d
> and were never needed in 3.5.10.

I would like to keep those patches in, as I strongly suspect that we were relying on undefined behaviour prior to their inclusion; i.e. even if the old code seems to work in most cases, it could fail at some point in the future or in an unusual use case.

Tim

Do we need to grep tqt3 for possible similar "misses" with all of the renamed bin files?

assistant -> tqassistant
designer  -> tqdesigner
linguist  -> tqlinguist
lrelease  -> tqlrelease
lupdate   -> tqlupdate
moc       -> tqmoc
qembed    -> tqembed
qmake     -> tqmake
qtconfig  -> tqtconfig
uic       -> tquic

If yes, what is the best way to search?

(In reply to comment #47)
> If yes, what is the best way to search?

A plain text search for the string "bin/<renamed file name>".

Tim

I'm closing this bug report as resolved.