From: Steve Pieper [mailto:pieper@ibility.net]
Sent: Tuesday, May 24, 2011 5:20 PM
To: Andras Lasso
Cc: slicer-devel@bwh.harvard.edu
Subject: Re: [slicer-devel] Slicer4 launcher problem

Hi Andras -

Very good catch - this will impact developers, but not users, since the python dll is put in the bin directory by the installer as part of cpack.

In general though it seems the windows side-by-side is the 'correct' solution for windows builds. Although it is a pain, it should probably be done automatically as part of the build process.

It looks like there's some support for this in cmake:

http://www.kitware.com/blog/home/post/4

Alternatively we could copy the python dlls (and others) into the Slicer-build/bin/<type> directory as part of the build process rather than as part of the packaging process.

-Steve

On Tue, May 24, 2011 at 11:00 AM, Andras Lasso <lasso@cs.queensu.ca> wrote:
Hi all,

I tried to build and test Slicer4 on Windows 7. The build was OK, but it
didn't start (error: [bin/Release/SlicerQT-real.exe] exit abnormally -
Report the problem.)

I've found that copying python26.dll into the ...\Slicer-build\bin\Release\
directory solves the problem. There is a c:\Windows\System32\python26.dll on
my system (installed by some application). If I remove the python26.dll from
system32 then Slicer starts correctly (there is no need to copy the new
python26.dll into the release directory). The python26.dll version in
system32 is 2.6.2, the Slicer-built python26.dll is 2.6.6.

The problem is that the launcher adds the Slicer directories to the PATH env
variable, but first the dlls are attempted to be loaded from the system
directories (http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx).
Therefore if any application installs any python, QT, ITK, VTK, etc. dll
into the system directories then Slicer may crash.

The problem was the same with Slicer3 and tcl, but probably tcl changed less
often or dll versions with the same filename (tcl84.dll) were more
compatible with each other than python. A safe solution could be to install
all the required dlls into the bin directory (then there would be no need
for a launcher at all) or use side-by-side assemblies to make sure that the
correct dll versions are loaded.

Andras

I also ran into this problem, and confirm that it was solved by deleting python26.dll from c:\windows\system32 directory.

After deleting python26.dll, I could no longer run python.exe. Perhaps the dll is installed to that location by an official windows python binary.

Andras> Would it be possible to confirm using dependency walker ?

Greg> Could you confirm that python.exe and python26.dll built by Slicer are located in the same folder ?

I confirm that dependency walker shows python26.dll is loaded from c:\windows\system32 if python26.dll is installed in the windows system directories and python26.dll is not available in the executable's directory.

This is the case when attempting to run Slicer from the build tree.

This would happen also if you started any exe that is not located in Slicer 4.1.0\bin uses python (or loads a python-using dll). Fortunately, with the current CLIs this cannot happen, as none of them use python. The problem may happen when somebody tries to launch a python scripted module from command line using python.exe.

The crash when starting Slicer from the build tree could be prevented by adding a line to one of the CMakeLists.txt files to copy Python26.dll into the SlicerQt-real.exe directory.

It was some time ago when I last checked this, but normally the Python installer copies:

• Python.exe (and many other files) into c:\Python26\python.exe
• Python26.dll into the windows system directories (it appears in c:\Windows\SysWOW64\python26.dll in the file system, depends reports c:\windows\system32)

It seems the problem is resolved. See enclosed screenshot

Dear issue reporter,

Good news :) Slicer developers SOLVED the problem you reported - YOU now need to VERIFY and CLOSE this issue.

The problem still exists. How to reproduce:

• Install the latest available Python 2.6.x release (http://www.python.org/download/releases/2.6.6/) with default options
  => it copies Python26.dll into the system directories (e.g., c:\Windows\System32\python26.dll)
• Start Slicer in release mode
  => After the splash screen disappears nothing appears, Slicer nevers starts up.

Notes:

1. If Slicer and Python release bitness (32-bit or 64-bit) is different then the problem does not occur. Installation of the 32-bit Python release breaks only the 32-bit Slicer release. Installation of the 64-bit Python release breaks only the 64-bit Slicer release.

2. Installed Slicer Releases are not impacted, because the Slicer application exe and Python26.dll are in the same directory.

3. The problem occurs with both release and debug builds.

This issue affects only developer and based on today hangout discussion, it has been re-targeted for 4.3

Same issue has cropped up again:

http://massmail.spl.harvard.edu/public-archives/slicer-devel/2013/012307.html

Updated documentation link to "Search Path Used by Windows to Locate a DLL"
See http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.90).aspx

1) Immediate solution: As part of the Slicer build process, we could copy the python library along side the qSlicerApp-real.exe executable.

2) Alternative/complementary solution: If there is a system python (matching the requirement) available on the windows machine, it could/should probably be used.

While solution (1) will fix that specific issue, should we detect if there are itk/qt/vtk/... already available on the system and warn the developer ? If not, unexpected problem will arise. Should we also copy DLL of VTK, ITK, ... along side the executable ?

We could also ask VTK/ITK/.. to build their library along side the Slicer executable. That would avoid issue but would prevent the developer from deleting Slicer-build inner directory without having to rebuild everything.

Note that this issue somehow became more problematic now (probably because of external reasons). While Andras and Greg could uninstall python 2.6 from their systems to get Slicer start up, I cannot start Slicer now, even after uninstalling Python 2.7. And this is confirmed on other computers too.

So an immediate solution (as in the previous comment) would be much appreciated.

@ungi: Could you investigate why Slicer fails to start even after removing the problematic from system folder. What is the output of dependency walker in that case.

Note that solution (1) will be implemented, Just want to have a better understanding of what is going on.

Have you tried using SetDllDirectory [1] to override the search path, so that the slicer directories are used first? If this is called by the launcher, then any subsequent loadlibrary calls within the process should respect the modified path.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms686203(v=vs.85).aspx

Seems that "SetDllDirectory" is useful when relying on "LoadLibrary" in case of explicit linking.

Some interesting readings about the topic:
http://www.binaryplanting.com/guidelinesDevelopers.htm
http://www.pretentiousname.com/setdlldirectory_inheritance/index.html
http://msdn.microsoft.com/en-us/library/784bt7z7%28v=VS.100%29.aspx

As explained here, explicit linking would be complex process for an application like Slicer: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/9a70abb2-ee8e-4c91-8d88-cdb213c5832e/

As of today, copying the python library along side the executable seems to be a good compromise.

If we encounter issue with VTK, ITK, .. libraries, we could also copy them along side the executable.

Dependency Walker says:
"e:\Slicer4\Debug\Slicer-build\PYTHON27.DLL was not found."
However, the file is there. I don't know why is it not found.

When staring Slicer from Visual Studio (in Debug 64-bit mode) it says in the output window:
'SlicerApp-real.exe': Loaded 'C:\Windows\System32\python27.dll'
However, the file is NOT there! And there aren't any other python27.dll files accessible on my computer (only the ones that come with Slicer).

Humm ... after doing a regular build, there are no file "e:\Slicer4\Debug\Slicer-build\PYTHON27.DLL" but "e:\Slicer4\Debug\Slicer-build\python-install\bin\python27.dll" should exist.

Do you confirm you started both dependency walker and visual studio using the slicer launcher ?

Sorry, you are right. None of the files exist.
Yes, I started both by Slicer.exe --launch ...

I deleted every entry from my Windows Registry that included "System32\python27". There were a few. But the problem is still the same when I try to run Slicer from Visual Studio.

Do you mean that the following file does not exist:
"e:\Slicer4\Debug\Slicer-build\python-install\bin\python27.dll"

If it does NOT exist, it means there is any issue building python that should be addressed first.

No.

e:\Slicer4\Debug\Slicer-build\PYTHON27.DLL
--- does not exist.

C:\Windows\System32\python27.dll
--- does not exist.

e:\Slicer4\Debug\Slicer-build\python-install\bin\python27.dll
--- exists. But sadly, Slicer is not looking for it when starting from Visual Studio...

Fixed in r21943
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21943

Follow up commit r21948
See http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&amp;revision=21948

It fixes error reported on the dashboard:

// ---------------
19>91>Copy 'python27.dll' along side 'SlicerApp-real' executable. See Slicer issue 0001180
19>91>Error copying file (if different) from "/python27.dll" to "/.../Slicer-1-build/Slicer-build/bin/Release".
19>91>Project : error PRJ0019: A tool returned an error code from "Copy 'python27.dll' along side 'SlicerApp-real' executable. See Slicer issue 0001180"
// ---------------

See http://slicer.cdash.org/viewBuildError.php?buildid=91379

Closing resolved issues that have not been updated in more than 3 months

Fix committed to 2145-support-for-installing-extension-from-file branch.