<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Obada Mahdi</b> <<a href="mailto:omahdi@gmx.de">omahdi@gmx.de</a>><br>Date: Nov 22, 2006 5:41 AM<br>Subject: Re: [vtkusers] Unable to port a vtk application to a computer which doesnt have vtk installed.
<br>To: rashed karim <<a href="mailto:rashed.vtk@googlemail.com">rashed.vtk@googlemail.com</a>><br><br></span>Hi Rashed!<br><br>On 11/22/06, rashed karim <<a href="mailto:rashed.vtk@googlemail.com">rashed.vtk@googlemail.com
</a>> wrote:<br>> On 11/22/06, Obada Mahdi <<a href="mailto:omahdi@gmx.de">omahdi@gmx.de</a>> wrote:<br>[...]<br>> Thanks for your quick reply. I only see .lib and .exe files in /bin meaning<br>> BUILD_SHARED_LIBS was probably set to off. In that case, are you saying that
<br>> I wouldn't need to copy anything to the other machine, and the .exe would<br>> run ok?<br><br>I would think so, at least on VTK's part. Also, if there were<br>problems with missing DLLs that were linked to the program by Visual
<br>Studio, the program would not even run, and, at best, cause the<br>operating system to play a funny sound and display an error message<br>complaining about missing components. If you want to be sure, you can<br>check
e.g. with the "Dependency Walker" on the target machine:<br><br><a href="http://www.dependencywalker.com/">http://www.dependencywalker.com/</a><br><br>It is a small tool that examines library dependencies and shows how
<br>they are resolved or if some are missing, much like "ldd" on GNU/Linux<br>systems.<br><br>> > If this does not help: How does the problem become manifest in the<br>> > target environment? Is there an error message? If there is, what
<br>> > does it say?<br><br>> I have tested it on two computers, one which had vtk installed (and probably<br>> a slightly older version, but > 5.0) and one which didnt.<br><br>If there are shared libraries involved, even small deviations can make
<br>a huge difference. Mixing library versions is generally not<br>supported, see below ("Checking DLL deps").<br><br>> On the computer<br>> with vtk, the error was displayed on a separate window which popped out
<br>> (just like all vtk run-time errors) and said something like vtkOutputWindow<br>> .. could not allocate memory .... that is how much I could read of the<br>> error. The rest of the line was truncated by the error window, which freezes
<br>> when you try to resize it.<br>><br>> In the other computer, which didnt have vtk installed, it simply got stuck<br>> at the point where the application tried to surface render some data.<br><br>I am afraid that I do not have a viable explanation for what causes
<br>those problems at the moment. It still strikes me as odd that in your<br>VTK installation the .lib files reside in the "bin" directory instead<br>of "lib" (but I might just have remembered that wrong) and there are
<br>no DLLs at all, while it makes a difference on which systems the<br>program is being run. In particular, if the program has been linked<br>purely static, the resulting executable is self-contained, and it<br>should not make a difference whether VTK is already installed or not.
<br><br>Anyway, I am not a Windows expert, but here are some other hints,<br>questions and suggestions:<br><br>First of all, to learn more about your configurations and maybe<br>eliminate some possibilities, some more information about your build
<br>and installation procedures would be of help, if at all available,<br>like:<br>- the "CMakeCache.txt" used for building VTK<br>- information on how your program is build (manually created project<br>in VS, or CMake-generated VS project; the former is an error-prone
<br>procedure)<br>- the full command line parameters the linker is invoked with<br><br>Checking DLL deps: What I would probably try in your situation now,<br>before approaching the problem from the root and testing whether
<br>pre-compiled, statically linked VTK programs run on the target machine<br>at all, is to use the aforementioned "Dependency Walker" to check for<br>any dynamic library dependencies. I don't know whether there is
<br>versioning information in DLLs which is checked while loading them;<br>but in case the build system and target system have different library<br>versions, weird things might happen, even if there are no reported<br>linker problems;
e.g., public symbol names did not change, but other<br>API-related stuff has. I know this can cause problems on GNU/Linux,<br>e.g. when stale .so files are found by the dynamic linker before the<br>recent ones.<br><br>Checking header files: Something similar is true for included .h
<br>files: Make sure that the VTK header files used for compiling your<br>program match _exactly_ the libraries from the VTK build you are<br>linking against. If in doubt, check the compiler/linker command line<br>options for correct library and header search paths. Even small
<br>differences in header files can cause significant and undefined<br>trouble if they do not match the library that is being used for<br>linking. However, this is most probably not a problem if the program<br>runs fine on the development system.
<br><br>Testing with small example: Do you happen to have compiled VTK<br>examples, like the "Cone" example or similar? It would be nice to<br>know whether they cause the same problems as your progam does.<br><br>
I don't have the time right now, but unless you manage to solve the<br>problem and/or someone else has a better idea, and if I find some<br>spare time, I could try to reproduce your deployment procedure on<br>WinXP systems with Visual Studio 8 and see if it works--given that you
<br>can provide a small example program (maybe one of the VTK examples<br>does the trick?) that causes similar problems on your configuration,<br>along with some information how you built it.<br><br><br>> Pardon me for being slightly vague. I really appreciate.
<br><br>No problem, and thank you for bearing with me and my wishy-washy suggestions :-)<br><br>Regards<br><br>Obada<br>