Qt-interest Archive, October 2007
Installing on WinXP
Message 1 in thread
Hello,
i'm developing (and building) my application on win Vista with VS2005
and would like to install it on WinXP. I therefore got a new installed
XP (on a Virtual Machine).
Even though i executed the vc_redist_x86.exe the app could not be
started because some dll's were missing (namely msvcr80.dll,
msvcr80p.dll, mmvcp70.dll, mmvcr70.dll and coredll.dll). After copying
all these in the app directory (interestingly the coredll.dll doesn't
even exist on my building machine) it now refuses to start with
"Die Ordnungszahl 1346 konnte nicht in coredll.dll gefunden werden"
(the ordinal number 1346 could not be found in coredll.dll)
What does all this mean?
Thx for any help,
RZ
--
[ signature omitted ]
Message 2 in thread
RZ schrub:
> Hello,
>
> i'm developing (and building) my application on win Vista with VS2005
> and would like to install it on WinXP. I therefore got a new installed
> XP (on a Virtual Machine).
> Even though i executed the vc_redist_x86.exe the app could not be
> started because some dll's were missing (namely msvcr80.dll,
> msvcr80p.dll, mmvcp70.dll, mmvcr70.dll and coredll.dll).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hmmm, according to Google mmvcp70.dll (and probably mmvcr70.dll as well,
see for instance http://forums.techarena.in/showthread.php?t=677059) are
MusicMatch DLLs - what kind of application are you trying to build, a
media player?
In any case, these DLLs are *not* installed by the vc_redist_x86.exe -
this distribution application only installs the VS2005 C++ runtime!
coredll.dll must be a DLL of your own or it is pulled in by some other
DLL (MusicMatch DLL?) you are linking with.
Try the Dependency Walker (depends.exe, comes with Visual Studio or get
it from here: www.dependencywalker.com) and find out which DLL/*.exe is
pulling in the wrong (mmvcp70
> After copying
> all these in the app directory (interestingly the coredll.dll doesn't
> even exist on my building machine) it now refuses to start with
> "Die Ordnungszahl 1346 konnte nicht in coredll.dll gefunden werden"
> (the ordinal number 1346 could not be found in coredll.dll)
>
> What does all this mean?
It means that the "ordinal number 1346 could not be found in
coredll.dll". ;)
So the question is: if this coredll.dll doesn't even exist on your
development platform (and I assume your application /does/ work there) -
/where/ did you get it from?! :)
In any case, it seems you got the wrong version which apparently is
missing some symbols I guess. To be honest I don't quite get the message
either, but I assume "Ordnungszahl" is the german translation of "enum"
here, so that would mean that this DLL is supposed to *export* an enum
value of '1346' somewhere... no?
Again, see Dependency Walker (try it on your development box and see
where this coredll.dll comes from!).
Cheers, Oliver
--
[ signature omitted ]
Message 3 in thread
Thx, for your answer - but things are still not how they should be.
Well, I got the "right" configuring (aka release mode) - so i can build
my app now using the appropriate switches and then deploy it (caveat:
the whole vcredist-thing doesn't help if your app relies on msvcrD80.dll
- it has to be msvcr80.dll).
But solving one thing leads to at least two new problems ;-)
Every customer gets its personal version of the app - so i wrote a build
script (perl) that auto-generates a Makefile and calls nmake (and some
other additional steps). Although tweaking the settings for compiling
and linking (= copying the command line from the project settings in vs)
i get an executable that's slightly smaller (1.23 compared to 1.24MB),
has not got an application icon and - of course - does not work
(complains about not finding msvcp80.dll - which it does not miss if the
executable generated with vs is used).
So my questions:
what else (building steps?) do i need to generate a 'full' exe?
why is vs2005 so damn crappy that one can't export a Makefile?
--
[ signature omitted ]
Message 4 in thread
RZ schrub:
> Thx, for your answer - but things are still not how they should be.
>
> Well, I got the "right" configuring (aka release mode) - so i can build
> my app now using the appropriate switches and then deploy it (caveat:
> the whole vcredist-thing doesn't help if your app relies on msvcrD80.dll
> - it has to be msvcr80.dll).
That just what is to be expected: msvcr*d*80 is a DEBUG runtime DLL and
it's for a good reason that vcredist does *not* deploy this: if you read
the EULA/license you will understand that you are not even allowed to
ship the DEBUG C++ runtime DLLs ;) Or so the story goes...
The vcredist application *only* deploys the RELEASE C++ runtime DLLs.
Anyway, if at least one of your DLLs/*.exe still depends on msvcrd80.dll
(DEBUG - or any other MS DLL which contains a 'd' in the name) then you
have for sure a wrong setting somewhere in your project and you are
*not* in release mode.
>
> But solving one thing leads to at least two new problems ;-)
>
> Every customer gets its personal version of the app - so i wrote a build
> script (perl) that auto-generates a Makefile and calls nmake (and some
Why so complicated? Either you use the already available Visual Studio
project/solution files *.vcproj and build them on the command line:
%PROGRAMS%\Microsoft Visual Studio 8\Common7\IDE\devenv.com"
..\YourSolution.sln /Rebuild "Release"
or use qmake and *.pro files. No one is supposed to write Makefiles on
their own nowadays ;) That's totally out of fashion, that's dirrrty,
that *eeeks*!
> other additional steps). Although tweaking the settings for compiling
> and linking (= copying the command line from the project settings in vs)
> i get an executable that's slightly smaller (1.23 compared to 1.24MB),
> has not got an application icon
Again, I strongly suggest you leave that dirty work to qmake! As for the
icon, I'm sure you are missing the resource compiler step (the Microsoft
resource compiler, not the Qt resource compiler!): With qmake that would
simply be in your *.pro
win32 {
RESOURCES += YourVisualStudioResourceFile.rc
}
> and - of course - does not work
> (complains about not finding msvcp80.dll - which it does not miss if the
> executable generated with vs is used).
Did you create and compile the manifest into the executable/DLL? I have
no idea how a Visual Studio Makefile works (and I don't want to ;) ),
but I'm sure a missing msvcp80.dll has to do with an
invalid/non-existant manifest file.
If you have a look at the Visual Studio output you'll see that there's a
manifest compilation stage shortly before the final linking.
Again, leave that stuff to qmake :)
> why is vs2005 so damn crappy that one can't export a Makefile?
Because no one wants to see it? ;)
Good luck, Oliver
--
[ signature omitted ]
Message 5 in thread
Till Oliver Knoll schrub:
> ...
> If you have a look at the Visual Studio output you'll see that there's a
> manifest compilation stage shortly before the final linking.
>
> Again, leave that stuff to qmake :)
And yet again another "one line solution" (how I love them) with qmake:
CONFIG += embed_manifest_exe
Note: the system simply refuses to link with the C++ runtime DLLs if
your application does not have a (valid) manifest file!
In theory you /can/ build an application by skipping the manifest
compilation step, but this app simply won't run when it depends on any
C/C++ function (and not doing so must be a pretty boring application ;) )
Cheers, Oliver
--
[ signature omitted ]
Message 6 in thread
> Von: Till Oliver Knoll
> Till Oliver Knoll schrub:
> > ...
> > If you have a look at the Visual Studio output you'll see that there's a
> > manifest compilation stage shortly before the final linking.
> >
> > Again, leave that stuff to qmake :)
>
> And yet again another "one line solution" (how I love them) with qmake:
>
> CONFIG += embed_manifest_exe
>
That's the default when using msvc2005 mkspec - no need to add it everywhere.
Christian
--
[ signature omitted ]
Message 7 in thread
Thx Oliver for all your help (i wasn't aware that vs2005 could be
started with switches from the command line).
It turned out i was thinking too complicated - somehow the manifest step
got lost; including that everything's fine now (again).
Anyway, i'll nominate you for the GVSE award (Great Visual Studio
Expert); no money but fame and honor ...
> Till Oliver Knoll schrub:
>> ...
>> If you have a look at the Visual Studio output you'll see that there's
>> a manifest compilation stage shortly before the final linking.
>>
>> Again, leave that stuff to qmake :)
>
> And yet again another "one line solution" (how I love them) with qmake:
>
> CONFIG += embed_manifest_exe
>
> Note: the system simply refuses to link with the C++ runtime DLLs if
> your application does not have a (valid) manifest file!
>
> In theory you /can/ build an application by skipping the manifest
> compilation step, but this app simply won't run when it depends on any
> C/C++ function (and not doing so must be a pretty boring application ;) )
>
> Cheers, Oliver
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
