[kde-freebsd] qt upgrade strangeness

Kris Kennaway kris at obsecurity.org
Tue Apr 17 19:26:09 UTC 2007


On Tue, Apr 17, 2007 at 09:22:58PM +0200, Dejan Lesjak wrote:
> On Tuesday 17 April 2007 20:58:42 Michael Nottebrock wrote:
> > On Tuesday, 17. April 2007, Dejan Lesjak wrote:
> > > On Tuesday 17 of April 2007, Michael Nottebrock wrote:
> > > > On Tuesday, 17. April 2007, Michael Nottebrock wrote:
> > > > > On Monday, 16. April 2007, Andy Fawcett wrote:
> > > > > > Hi,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: John Nielsen [mailto:lists at jnielsen.net]
> > > > > > > Sent: Thursday, April 05, 2007 19:32
> > > > > > > To: kde at freebsd.org
> > > > > > > Cc: x11 at freebsd.org
> > > > > > > Subject: Re: [kde-freebsd] qt upgrade strangeness
> > > > > > >
> > > > > > > On Thursday 05 April 2007 12:29:27 pm John Nielsen wrote:
> > > > > > > > I've had some trouble upgrading qt on two different machines
> > > > > > > > now. I'm
> > > > > > >
> > > > > > > using
> > > > > > >
> > > > > > > > the experimental Xorg git ports tree on both and I'm not sure
> > > > > > > > if that's
> > > > > > >
> > > > > > > a
> > > > > > >
> > > > > > > > factor, which is why I'm CC-ing x11 at .
> > > > > > > >
> > > > > > > > In short, qt will install happily the first time but not the
> > > > > > > > second. It looks to my untrained eye like building [an
> > > > > > > > upgraded] qt when qt is
> > > > > > >
> > > > > > > already
> > > > > > >
> > > > > > > > installed somehow taints the build. The build will complete
> > > > > > >
> > > > > > > successfully,
> > > > > > >
> > > > > > > > but it will fail during the install step whether or not the old
> > > > > > > > qt was uninstalled between the make and install steps--I tried
> > > > > > > > an install
> > > > > > >
> > > > > > > without
> > > > > > >
> > > > > > > > uninstalling the old one using FORCE_PKG_REGISTER and it failed
> > > > > > > > differently, but it still failed. However, if qt and qmake are
> > > > > > > > removed completely before starting the [new] build for qt, it
> > > > > > > > will install just fine.
> > > > > > > >
> > > > > > > > I'd like to determine if 1) this is a known problem and 2) this
> > > > > > > > is
> > > > > > >
> > > > > > > specific
> > > > > > >
> > > > > > > > to the Xorg ports tree so I know whether or not to send in a
> > > > > > > > PR.
> > > > > > >
> > > > > > > I forgot to mention this was during an attempt to update qt from
> > > > > > > qt-copy- 3.3.8
> > > > > > > to qt-copy-3.3.8_1 on a 7-CURRENT (as of several days ago) box. I
> > > > > > > also saw the problem on a previous qt upgrade on a machine
> > > > > > > running 6-STABLE several weeks ago.
> > > > > >
> > > > > > Originally I reported that I wasn't seeing this.
> > > > > >
> > > > > > Now, I've just updated to the very latest git X11 ports, with
> > > > > > X11BASE migrated to LOCALBASE, and get this problem.
> > > > > >
> > > > > > cd src/moc && make
> > > > > > cd src/moc && make install
> > > > > > cp -f "../../bin/moc" "/usr/local/bin/moc"
> > > > > > cd src && make
> > > > > > make: don't know how to make /usr/local/include/qconfig.h. Stop
> > > > > > *** Error code 2
> > > > > >
> > > > > >
> > > > > > Quite weird, I've never seen this before.
> > > > >
> > > > > I dimly remember seeing that before - I don't think Qt/qmake can
> > > > > actually handle a PREFIX-move cleanly and once the prefix has
> > > > > changed, it has to be deinstalled *before* rebuilding it, or else
> > > > > this will happen.
> > > >
> > > > Since I understand there will be an update script for the upcoming
> > > > X.org upheaval, this issue would be a prime candidate for handling it
> > > > in such a script. flz, lesi, what do you think?
> > >
> > > Would bumping revision of qmake and qt be enough or were you thinking of
> > > something more aggressive?
> >
> > No - I'm guessing the problem is that qmake generates wrong dependencies in
> > Makefiles when it configures Qt with a prefix that is different from the
> > one of a previously installed Qt, with the dependencies being generated on
> > files in the destination install prefix instead of the workdir. The most
> > obvious workaround: Deinstall (as in make deinstall) qt33, then (and only
> > then) rebuild and reinstall qt33 with the new PREFIX set. An update script
> > could take care of this rather easily as part of a post-update cleanup
> > routine.
> >
> > I can also try to reproduce this and, if I succeed, try to come up with
> > some post-configure in-place Makefile editing, if my guess turns out to be
> > correct, but I am still busy with changing a number of qt4 ports to avoid
> > conflicting with qt33 after the X11BASE-move and flz@ already told me would
> > very much like to remain on schedule and do the merge on the upcoming
> > monday - I'm simply not sure I will be able to address this problem in
> > time.
> 
> Errrrm...  does this failure happen with /usr/X11R6 -> /usr/local symlink in 
> place or without it?

Without, presumably - that symlink can only be added after the
upgrade, once everything has been rebuilt, so it won't help with
failures trying to perform that rebuild.

Kris


More information about the freebsd-x11 mailing list