iv3d-users

Text archives Help


[IV3D-USERS] Re: Re: Re: Trouble building with QT 4.7, Windows 7


Chronological Thread 
  • From: tom fogal <tfogal@sci.utah.edu>
  • To: iv3d-users@sci.utah.edu
  • Subject: [IV3D-USERS] Re: Re: Re: Trouble building with QT 4.7, Windows 7
  • Date: Sun, 31 Oct 2010 10:10:05 -0600
Ofri Sadowsky <sadowsky.o.phd@gmail.com> writes:
> Here's how things turned out so far.  I got the Qt source have
> gone through the build, which was long enough to be sure...  Now
> QtOpenGLd.lib and qtmaind.lib (and their non-d versions) are in the
> lib directory of the fresh Qt.  And yet the build of ImageVis3D
> fails, now missing the library qjpegd.lib.  I suppose it should have
> been in the plugins/imageformats folder of Qt, but it ain't there.

I haven't tested it with the latest Qt releases.  I'll give that a try
on Monday; sounds like they changed something and we now have a bug :(

I believe the last version we've verified locally is 4.6.2.  Maybe
someone else can pipe in...

> I did use the configure command posted on your web page,
>
>   https://code.sci.utah.edu/svn/imagevis3d/Scripts/Win-StaticQt.bat
>
> (whose certificate, by the way, is not recognized by my browser) and
> I presume by the listed options that it was supposed to build the
> jpeg library.  Except it didn't.  And, by the way, the piped `echo
> y' you present isn't working with the current distribution of Qt.
> This is because Qt asks me if I am configuring an "Open Source" or
> "Commercial" package, to which the answer is "o" or "c" but not "y".

It (used to, at least) ask two questions, and we're just bypassing one
of them.  Do you have a patch to fix it?

> The installed Qt doesn't contain the qtjpegd.lib file either.
> Rather, it's qjpegd4.dll, with no lib.
>
> So back to square 1.

Try 4.6.2, for now.

-tom

> On Sun, Oct 31, 2010 at 10:28 AM, Ofri Sadowsky 
> <sadowsky.o.phd@gmail.com>wro
> te:
> 
> >  Thanks for the quick response.
> >
> > I installed the VS 2008, which seems to include the service pack already.
> >
> > The qmake+nmake combination still fails.  The error message from nmake (in
> > the VS 2008 comand shell) is:
> >
> >    NMAKE : fatal error U1052: file 'Makefile.Debug' not found
> >
> > I did set the env variable QTDIR32 to the installation folder of Qt.  This
> > enables me to compile the source files in the VS 2008 IDE.  But the build
> > fails at the link stage.  The linker looks for the libraries QtOpenGLd.lib
> > and qtmaind.lib (I am compiling for debug).  These libraries do not exist 
> > i
> n
> > Windows naming convention in my installation of Qt.  Instead, I have a 
> > bunc
> h
> > of lib***.a files and another bunch of ***.prl files.
> > I suppose one way to try and resolve this is to go back and build Qt from
> > source rather than install the binary.  I may take this step later on.  
> > For
> > now, I am still looking around.
> >
> > Have you considered porting the build process to CMake?  I'm no CMake
> > expert, but in my experience it handles this type of naming convention
> > variations reasonalby well.  It also allows you to configure the project
> > independently for a large set of compilers.  I suppose you can find 
> > reasons
> > for not using it as well.
> >
> > Ofri
> >
> > On Wed, Oct 27, 2010 at 6:03 PM, tom fogal <tfogal@sci.utah.edu> wrote:
> >
> >> <sadowsky.o.phd@gmail.com> writes:
> >> > I obtained the SVN version of the ImageVis3D source according to the
> >> > instructions on your web site, and I am trying to build it.
> >> >
> >> > My work environment is Windows 7/x64 with a Visual Studio 8 (that's
> >> > what I got).  Th Solution/Project files included in the SVN are
> >> > incompatible with VS 8, so I can't open them.
> >>
> >> You cannot use VS8.  You must use VS 2008 *with* the feature pack
> >> installed.  2010 support is on our todo list.
> >>
> >> 2008 express should be fine, as long as the feature pack is installed.
> >> 2010 will work 'out of the box' once we get around to it.
> >>
> >> > I therefore installed the Qt SDK 4.7 on the system.  This is NOT the
> >> > Qt source, but I figured I shouldn't have to go that far in order to
> >> > build ImageVis3D.
> >>
> >> You do have to go that far.  We have some guesses how to get it going
> >> otherwise, but we say we don't support the SDK because it's a very
> >> different Qt configuration and, well, we can't support everything.
> >>
> >> > I open the Qt Command Prompt and run qmake.  I get a bunch of
> >> > messages, some of them similar to the following.
> >> >
> >> > ***
> >> > WARNING: Unable to generate output for:
> >> > E:/ImageVis3D/ExtractDebugInfo/Makefile.Debug [TEMPLATE vcapp]
> >> > ***
> >> >
> >> > It doesn't appear as though the build was completed.  I afterwards
> >> > run nmake / gmake, and get error message such as:
> >>
> >> qmake does not build the software, only the makefiles.  So, yes, the
> >> build is not completed, but it hasn't been attempted either ;)
> >>
> >> ExtractDebugInfo is worthless for a user anyway; you might consider
> >> just removing it from the toplevel .pro.
> >>
> >> > ***
> >> > cd Tuvok\ && gmake -f Makefile
> >> > gmake[1]: Entering directory `E:/ImageVis3D/Tuvok'
> >> > gmake -f Makefile.Debug
> >> > gmake[2]: Entering directory `E:/ImageVis3D/Tuvok'
> >> > gmake[2]: Makefile.Debug: No such file or directory
> >> > gmake[2]: *** No rule to make target `Makefile.Debug'.        Stop.
> >> > gmake[2]: Leaving directory `E:/ImageVis3D/Tuvok'
> >> > gmake[1]: *** [debug] Error 2
> >> > gmake[1]: Leaving directory `E:/ImageVis3D/Tuvok'
> >> > gmake: *** [sub-Tuvok-make_default-ordered] Error 2
> >> > ***
> >> >
> >> > Essentially, the build fails in this environment.  Could you explain
> >> > why?  If the Qt source version is needed, then also please explain
> >> > why.
> >>
> >> The SDK installs the libraries with different names.  This is basically
> >> impossible to support in a solution file, because if you use 'name1',
> >> it'll fail with static linking, and if you use 'name2' it'll fail when
> >> someone has a dynamic Qt.  We standardized on static linking, at least
> >> on windows.
> >>
> >> Secondly, qmake is broken on windows.  See bug 452 in their BTS.  We
> >> had a plethora of issues getting the qmake-generated makefiles to even
> >> build 10-line Qt programs on that platform at first.  I fixed those
> >> maybe 6 months back by fiddling with our .pro's considerably, but 452
> >> is still a blocker for us.  Hence building through any other method
> >> than via the solution files is unsupported.
> >>
> >> That said, I would appreciate you reporting to this list how you got it
> >> working if you do so via a different path.
> >>
> >> Also, if you fix Qt's 452 I'll gladly jump in and make sure qmake-based
> >> building works on Windows; it's something I want for the regression
> >> testing system anyway.

Archive powered by MHonArc 2.6.16.

Top of page