Fwd: [vtkusers] Unable to port a vtk application to a computer which doesnt have vtk installed.

[rashed karim]

---------- Forwarded message ----------
From: Obada Mahdi <omahdi at gmx.de>
Date: Nov 22, 2006 5:41 AM
Subject: Re: [vtkusers] Unable to port a vtk application to a computer which
doesnt have vtk installed.
To: rashed karim <rashed.vtk at googlemail.com>

Hi Rashed!

On 11/22/06, rashed karim <rashed.vtk at googlemail.com> wrote:
> On 11/22/06, Obada Mahdi <omahdi at gmx.de> wrote:
[...]
> Thanks for your quick reply. I only see .lib and .exe files in /bin
meaning
> BUILD_SHARED_LIBS was probably set to off. In that case, are you saying
that
> I wouldn't need to copy anything to the other machine, and the .exe would
> run ok?

I would think so, at least on VTK's part.  Also, if there were
problems with missing DLLs that were linked to the program by Visual
Studio, the program would not even run, and, at best, cause the
operating system to play a funny sound and display an error message
complaining about missing components.  If you want to be sure, you can
check e.g. with the "Dependency Walker" on the target machine:

http://www.dependencywalker.com/

It is a small tool that examines library dependencies and shows how
they are resolved or if some are missing, much like "ldd" on GNU/Linux
systems.

> > If this does not help: How does the problem become manifest in the
> > target environment?  Is there an error message?  If there is, what
> > does it say?

> I have tested it on two computers, one which had vtk installed (and
probably
> a slightly older version, but > 5.0) and one which didnt.

If there are shared libraries involved, even small deviations can make
a huge difference.  Mixing library versions is generally not
supported, see below ("Checking DLL deps").

> On the computer
> with vtk, the error was displayed on a separate window which popped out
> (just like all vtk run-time errors) and said something like
vtkOutputWindow
> .. could not allocate memory .... that is how much I could read of the
> error. The rest of the line was truncated by the error window, which
freezes
> when you try to resize it.
>
> In the other computer, which didnt have vtk installed, it simply got stuck
> at the point where the application tried to surface render some data.

I am afraid that I do not have a viable explanation for what causes
those problems at the moment.  It still strikes me as odd that in your
VTK installation the .lib files reside in the "bin" directory instead
of "lib" (but I might just have remembered that wrong) and there are
no DLLs at all, while it makes a difference on which systems the
program is being run.  In particular, if the program has been linked
purely static, the resulting executable is self-contained, and it
should not make a difference whether VTK is already installed or not.

Anyway, I am not a Windows expert, but here are some other hints,
questions and suggestions:

First of all, to learn more about your configurations and maybe
eliminate some possibilities, some more information about your build
and installation procedures would be of help, if at all available,
like:
- the "CMakeCache.txt" used for building VTK
- information on how your program is build (manually created project
in VS, or CMake-generated VS project; the former is an error-prone
procedure)
- the full command line parameters the linker is invoked with

Checking DLL deps: What I would probably try in your situation now,
before approaching the problem from the root and testing whether
pre-compiled, statically linked VTK programs run on the target machine
at all, is to use the aforementioned "Dependency Walker" to check for
any dynamic library dependencies.  I don't know whether there is
versioning information in DLLs which is checked while loading them;
but in case the build system and target system have different library
versions, weird things might happen, even if there are no reported
linker problems; e.g., public symbol names did not change, but other
API-related stuff has. I know this can cause problems on GNU/Linux,
e.g. when stale .so files are found by the dynamic linker before the
recent ones.

Checking header files: Something similar is true for included .h
files: Make sure that the VTK header files used for compiling your
program match _exactly_ the libraries from the VTK build you are
linking against.  If in doubt, check the compiler/linker command line
options for correct library and header search paths.  Even small
differences in header files can cause significant and undefined
trouble if they do not match the library that is being used for
linking.  However, this is most probably not a problem if the program
runs fine on the development system.

Testing with small example: Do you happen to have compiled VTK
examples, like the "Cone" example or similar?  It would be nice to
know whether they cause the same problems as your progam does.

I don't have the time right now, but unless you manage to solve the
problem and/or someone else has a better idea, and if I find some
spare time, I could try to reproduce your deployment procedure on
WinXP systems with Visual Studio 8 and see if it works--given that you
can provide a small example program (maybe one of the VTK examples
does the trick?) that causes similar problems on your configuration,
along with some information how you built it.


> Pardon me for being slightly vague. I really appreciate.

No problem, and thank you for bearing with me and my wishy-washy suggestions
:-)

Regards

Obada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20061122/a8346b39/attachment.htm>