Qt-interest Archive, January 2008
Qt3 uic, qt_plugins_3.3rc file
Message 1 in thread
Hi!
Is there a possibility to make uic from Qt3 not create qt_plugins_3.3rc
file (on my system it gets crated in /usr/local/etc/settings)?
The problem is that during the build process of one program I'm creating
FreeBSD port of (lprof.sf.net), uic gets invoked as:
/usr/local/bin/uic -impl lprofmainbase.h -o build/freebsd/lprofqt/uic_lprofmainbase.cc src/lprofqt/lprofmainbase.ui
creates that /usr/local/etc/settings/qt_plugins_3.3rc file, which leads
to build failure, as FreeBSD ports are required not to touch anything
outside their build directory until installation phase.
--
[ signature omitted ]
Message 2 in thread
Hi,
> The problem is that during the build process of one program I'm creating
> FreeBSD port of (lprof.sf.net), uic gets invoked as:
>
> /usr/local/bin/uic -impl lprofmainbase.h -o build/freebsd/lprofqt/uic_lprofmainbase.cc src/lprofqt/lprofmainbase.ui
>
> creates that /usr/local/etc/settings/qt_plugins_3.3rc file, which leads
> to build failure, as FreeBSD ports are required not to touch anything
> outside their build directory until installation phase.
Are you certain uic attempts to create this file? I would expect it to only
try to read it.
FreeBSD is tested internally and FreeBSD Qt and KDE packages are also
available. Such a bug should have been detected earlier.
--
[ signature omitted ]
Message 3 in thread
* Dimitri (dimitri@xxxxxxxxxxxxx) wrote:
>> creates that /usr/local/etc/settings/qt_plugins_3.3rc file, which leads
>> to build failure, as FreeBSD ports are required not to touch anything
>> outside their build directory until installation phase.
> Are you certain uic attempts to create this file? I would expect it to only
> try to read it.
I am. I've created wrapper around uic and it shows that the file is only
created when uic is called with -impl:
-- no qt_plugins_3.3rc
/usr/local/bin/uic -o build/freebsd/lprofqt/lprofmainbase.h src/lprofqt/lprofmainbase.ui
-- no qt_plugins_3.3rc
/usr/local/bin/uic -impl lprofmainbase.h -o build/freebsd/lprofqt/uic_lprofmainbase.cc src/lprofqt/lprofmainbase.ui
-- now qt_plugins_3.3rc exists
The same command launched under ktrace confirms it (uic1 is renamed uic,
as uic is now my wrapper):
...
67972 uic1 CALL mkdir(0x28d647e0,S_IRUSR|S_IWUSR|S_IXUSR|S_IRGRP|S_IWGRP|S_IXGRP|S_IROTH|S_IWOTH|S_IXOTH)
67972 uic1 NAMI "/usr/local/etc/settings"
67972 uic1 RET mkdir 0
...
67972 uic1 CALL open(0x28d5f940,O_RDWR|O_CREAT,S_IRUSR|S_IWUSR)
67972 uic1 NAMI "/usr/local/etc/settings/.qt_plugins_3.3rc.lock"
67972 uic1 RET open 5
67972 uic1 CALL fcntl(0x5,F_SETLKW,0xbfbfc984)
67972 uic1 RET fcntl 0
67972 uic1 CALL open(0x28d5f940,O_WRONLY|O_CREAT|O_TRUNC,S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
67972 uic1 NAMI "/usr/local/etc/settings/qt_plugins_3.3rc.tmp"
67972 uic1 RET open 6
...
67972 uic1 CALL rename(0x28d5f970,0x28d5f940)
67972 uic1 NAMI "/usr/local/etc/settings/qt_plugins_3.3rc.tmp"
67972 uic1 NAMI "/usr/local/etc/settings/qt_plugins_3.3rc"
67972 uic1 RET rename 0
...
I've tried to rebuild some qt3 apps I use, but I didn't find one that
uses uic -impl, so this may not appear widely.
So if this is a bug, I hope Qt3 may be patched to fix it? I think I
could do it and it will get accepted to FreeBSD qt port, but I didn't yet
manage to find code related to this qt_plugins_3.3rc in qt code. Or is
there a way to workaround this? Say, some environment variable to make
uic create that file in ports' build directory insted of /usr/local/etc?
I can think of bundling uic_*cc with the port, but that'd be really
dirty :)
--
[ signature omitted ]
Message 4 in thread
Hi,
> I am. I've created wrapper around uic and it shows that the file is only
> created when uic is called with -impl:
>
> -- no qt_plugins_3.3rc
> /usr/local/bin/uic -o build/freebsd/lprofqt/lprofmainbase.h src/lprofqt/lprofmainbase.ui
> -- no qt_plugins_3.3rc
> /usr/local/bin/uic -impl lprofmainbase.h -o build/freebsd/lprofqt/uic_lprofmainbase.cc src/lprofqt/lprofmainbase.ui
> -- now qt_plugins_3.3rc exists
OK, I didn't have time to look into this in detail, but indeed I don't
understand why uic would need to modify its global settings. On the other hand
there's nothing wrong with it: an application should be able to modify its
global settings when run with appropriate rights (as root for example).
I wonder why this wasn't reported before though, since Qt 3 used to be
supported and developed under FreeBSD.
> [...]
> So if this is a bug, I hope Qt3 may be patched to fix it? [...]
Qt 3 has reached end-of-life so it will not be patched. You can still provide
a patch to the FreeBSD port.
--
[ signature omitted ]
Message 5 in thread
Hi,
> OK, I didn't have time to look into this in detail, but indeed I don't
> understand why uic would need to modify its global settings. On the
> other hand there's nothing wrong with it: an application should be able
> to modify its global settings when run with appropriate rights (as root
> for example).
The more I think of it, the less this looks like a bug. A program has every
right to write to a log file in /var/log or modify its settings on its first
run in /usr/local/etc - even when this program is used within a build process.
Who or what complains about that?
--
[ signature omitted ]
Message 6 in thread
* Dimitri (dimitri@xxxxxxxxxxxxx) wrote:
>> OK, I didn't have time to look into this in detail, but indeed I don't
>> understand why uic would need to modify its global settings. On the other
>> hand there's nothing wrong with it: an application should be able to
>> modify its global settings when run with appropriate rights (as root for
>> example).
> The more I think of it, the less this looks like a bug. A program has every
> right to write to a log file in /var/log or modify its settings on its
> first run in /usr/local/etc - even when this program is used within a build
> process.
Build tools are usually required to provide repeatable results, so
they shouldn't have config files at all (thus, say, gcc, can be
used with distcc easily). Also, it's impossible to use packaging
and such config file handling together - when app installed with
untar'ring bunch of files, there's no way to add/remove lines to
some config file. Also, I haven't ever seen software modifying
systemwide configs of itself. Anyway, that qt_plugins_3.3rc seem
more like cache that real configuration file.
> Who or what complains about that?
Automated package building tools for FreeBSD.
Here's the log for an app I'm porting:
http://head.miwibox.org/tb/errors/6.3-FreeBSD/lprof-1.11.4.1.log
the error is in the end of it.
Bundling generated files with the port is possible, but that's not
the best solution. First, they may be large (~1MB for this lprof
software, while port size is 5KB). Next, it's kinda hard to make build
tools not launch uic even when the generated files are already present
(even after playing with mtimes).
--
[ signature omitted ]
Message 7 in thread
Hi,
> Build tools are usually required to provide repeatable results, so
> they shouldn't have config files at all (thus, say, gcc, can be
> used with distcc easily). Also, it's impossible to use packaging
But then gcc, ccache and distcc don't fit the bill: they all have config
files. Please read on.
> and such config file handling together - when app installed with
> untar'ring bunch of files, there's no way to add/remove lines to
> some config file. Also, I haven't ever seen software modifying
> systemwide configs of itself. Anyway, that qt_plugins_3.3rc seem
> more like cache that real configuration file.
Exactly, I think the problem is not the existence of a file in /etc, but the
application creating/modifying it. As a cache, this file should probably live
in /var rather than /etc. Note that writing a cache in /var is OK in my
opinion, and results should be repeatable since this is a cache file. This is
similar to what ccache does.
Anyway, since this stuff is based on QSettings, it's hard to change - and Qt 3
has reached end-of-life.
--
[ signature omitted ]
Message 8 in thread
Hi,
> So if this is a bug, I hope Qt3 may be patched to fix it? I think I
> could do it and it will get accepted to FreeBSD qt port, but I didn't yet
> manage to find code related to this qt_plugins_3.3rc in qt code. [...]
I can reproduce that myself on Linux:
$ ls .qt/qt_plugins_3.3rc
ls: cannot access .qt/qt_plugins_3.3rc: No such file or directory
$
$ /usr/lib/qt-3.3/bin/uic foo.ui -o /dev/null
$
$ ls .qt/qt_plugins_3.3rc
ls: cannot access .qt/qt_plugins_3.3rc: No such file or directory
$
$ /usr/lib/qt-3.3/bin/uic -impl foo.h foo.ui -o /dev/null
$
$ ls .qt/qt_plugins_3.3rc
.qt/qt_plugins_3.3rc
$
Accessing ~/.qt/qt_plugins_3.3rc or /usr/local/etc/settings/qt_plugins_3.3rc
is caused by the use of QSettings. The only place in Qt source code where I
was able to find related code is in src/tools/qcomlibrary.cpp:
void QComLibrary::createInstanceInternal()
{
[...]
QString regkey = QString("/Qt Plugins %1.%2/%3")
.arg( ( QT_VERSION & 0xff0000 ) >> 16 )
.arg( ( QT_VERSION & 0xff00 ) >> 8 )
.arg( library() );
[...]
if ( ! cache ) {
cache = new QSettings;
[...]
if ( queried != reg ) {
cache->writeEntry( regkey, queried );
// delete the cache, which forces the settings to be written
delete cache;
[...]
This is just a starting point... I hope it helps you investigate this issue.
--
[ signature omitted ]
Message 9 in thread
On January 24, 2008 07:16:22 pm Dmitry Marakasov wrote:
> Hi!
>
> Is there a possibility to make uic from Qt3 not create qt_plugins_3.3rc
> file (on my system it gets crated in /usr/local/etc/settings)?
>
> The problem is that during the build process of one program I'm creating
> FreeBSD port of (lprof.sf.net), uic gets invoked as:
>
> /usr/local/bin/uic -impl lprofmainbase.h -o
> build/freebsd/lprofqt/uic_lprofmainbase.cc src/lprofqt/lprofmainbase.ui
>
> creates that /usr/local/etc/settings/qt_plugins_3.3rc file, which leads
> to build failure, as FreeBSD ports are required not to touch anything
> outside their build directory until installation phase.
I'm not aware of any way of stopping that, but note that you COULD ship
uic_lprofmainbase.cc, admittedly a generated file, and then there'd be no
reason to call uic in the first place.
--
[ signature omitted ]
