How Does R Build a Package with C Source Code?

According to Writing R Extensions, I put C files into a package subdirectory and supply a configure.ac and Makevars.in, and the command “R CMD INSTALL” will compile the extensions. I’m working in Linux, so it uses configure somehow, but what exactly does it do? Where do the defaults come from and how can I change them? As of R version 2.12.1, the build scripts are in the R tools package, no longer written in Perl.

There are a lot of files to put in an R package, from help files to a general description of the library. We are concerned with these three, as an example, for a library called foo.

• foo/configure.ac - Input to create a configure script.
• foo/src/Makevars.in - The configure script will create Makevars from this file.
• foo/src/foo.c - This is our C source to compile.

There are three commands R makes available to work with source while you develop it.

• R CMD build foo - This creates a tar file of the directory suitable for installing later.
• R CMD INSTALL foo - This compiles and installs foo into a directory.
• R CMD check foo - This does all kinds of detailed checks on the health of the R package, all listed in Writing R Extensions, and it also calls R CMD install, so it’s a good way to smoke test compilation.

If you call “R CMD check foo”, then it calls the library tools:::.check_packages() which eventually installs the library into a local directory by calling R again:

R CMD INSTALL -l '/home/username/Documents/rlib/foo.Rcheck' --no-html --no-multiarch '/Users/ajd27/Documents/rlib/foo'

As an aside, calling “R CMD blah” sets R environment variables and then invokes a shell script which looks for a script called blah in R’s bin directory. If it doesn’t find one, it just executes whatever you passed it. Try “R CMD ls -la .” or “R CMD env|sort” to see what environment variables R defines.

The install command is implemented in tools:::.install_packages(). The easiest way to see what it does is to look in the R source code, in the src/library/tools/R/install.R. It executes these steps on your behalf.

1. Define R-specific variables. These are listed below for one sample.
2. Call autoconf to create foo/configure from foo/configure.ac.
3. Call foo/configure, whose main goal is to make foo/src/Makevars from foo/src/Makevars.in.
4. Look for makefiles in foo/src and call make in foo/src to create shared libraries.

We can specify arguments to configure on the INSTALL command line, with --configure-args and --configure-vars. For instance, typing

R CMD INSTALL “--configure-args=--enable-lizards --disable-frogs”

will call

./configure --enable-lizards --disable-frogs

Use of quotation marks varies depending on the shell. The only way R modifies the execution of the configure command is to define the variables listed at the end of this post. The Guide to Writing R Extensions, however, recommends that authors of configure scripts use R to set defaults using R’s config command. Try

R CMD config --help

to see a list of variables R remembers from when it was configured and compiled.

When R calls make, it tacks a few files together. The first is the Makevars that configure just customized. The next is a list of variables, mostly from when R, itself, was configured. The last, shlib, is the target to build a shared library.

make -f Makevars -f /opt/local/lib/R/etc/x86_64/Makeconf -f /opt/local/lib/R/share/make/shlib.mk SHLIB='foo.so' OBJECTS='foo.o'

The only variables not defined explicitly with Makeconf are

• PKG_CFLAGS - Where includes go.
• PKG_CPPFLAGS - For the C preprocessor, if relevant.
• PKG_CXXFLAGS - For the C++ compiler.
• PKG_OBJCFLAGS - Objective C’s CFLAGS.
• PKG_OBJCXXFLAGS - Objective C++’s CFLAGS.
• PKG_LIBS - Where we put libraries and the directories that hold them.

These are the only variables we should bother to define within Makevars.in. Everything else, from CXX to CFLAGS, is already explicitly within Makeconf, so tough cookies if we want to change it, unless we are willing to make a custom target in our own Makefile in the src directory.

For our package, foo, we want to give the person installing the software a way to customize the include directories and library locations, so we probably want to check in our configure.ac for the existence of FOO_CFLAGS and FOO_LIBS and assign those values to PKG_CFLAGS and PKG_LIBS. Using package-specific naming helps when there are multiple packages installed, an using variables at all helps people installing avoid figuring out how to pass command-line arguments to R.

Sample Variables Defined Before Configure and Make

AWK=awk
DYLD_LIBRARY_PATH=/opt/local/lib/R/lib/x86_64
EGREP=/usr/bin/grep -E
LN_S=ln -s
MAKE=make
PAGER=/usr/bin/less
PERL=/opt/local/bin/perl
R_ARCH=/x86_64
R_BROWSER=/opt/local/bin/kfmclient
R_BZIPCMD=/opt/local/bin/bzip2
R_DOC_DIR=/opt/local/lib/R/doc
R_GZIPCMD=/opt/local/bin/gzip
R_HOME=/opt/local/lib/R
R_INCLUDE_DIR=/opt/local/lib/R/include
R_LIBRARY_DIR=/Users/username/Documents/rlib/foo.Rcheck
R_LIBS=/Users/ajd27/Documents/rlib/foo.Rcheck
R_LIBS_SITE=
R_LIBS_USER=~/R/x86_64-apple-darwin10.6.0-library/2.12
R_PACKAGE_DIR=/Users/ajd27/Documents/rlib/foo.Rcheck/foo
R_PACKAGE_NAME=foo
R_PAPERSIZE=letter
R_PDFVIEWER=/opt/local/bin/ggv
R_PLATFORM=x86_64-apple-darwin10.6.0
R_PRINTCMD=lpr
R_RD4DVI=ae
R_RD4PDF=times,hyper
R_SESSION_TMPDIR=/var/folders/4Z/4ZJIk-FGFl4hDOSWoQMBmU+++TI/-Tmp-//Rtmp3r18dL
R_SHARE_DIR=/opt/local/lib/R/share
R_TEXI2DVICMD=/opt/local/bin/texi2dvi
R_UNZIPCMD=/usr/bin/unzip
R_ZIPCMD=/usr/bin/zip
SED=/usr/bin/sed
TAR=/usr/bin/gnutar
TR=/usr/bin/tr
WHICH=/usr/bin/which

Installing Rmpi under Linux on Ranger at TACC

Rmpi is a package for the R language to allow it to use MPI to run in parallel. Installation on Ranger is complicated by Ranger's selection of compilers, MPI libraries, and default installed packages. I got it to work, so here are hints.

R's default compiler options for installed packages are the same as those used to compile R. The Ranger copy of R was compiled with gcc. MPI libraries on Ranger are compiled with either PGI or Intel compilers, and there can be incompatibilities loading shared libraries from PGI and Intel into gcc code (especially the version of PGI on Ranger). An easy way to get started healthily is to recompile R with the Intel compilers, so "module swap pgi intel" and configure a home directory installation of R using mpicc, mpicxx, and mpif90 with the Known Good Intel options for Ranger, "-O2 -xW -fPIC".

The Rmpi library depends on the R wrapper for the SPRNG library which, of course, depends on SPRNG itself. It also needs gmp. Ranger's gmp library is just fine, so "module add gmp". If you want to know includes and libs for any Ranger library, use "module help ". The SPRNG library has a problem, though, because it wasn't compiled with -fPIC, which is necessary to build shared libraries on this platform.

Rmpi needs SPRNG 2.0, no other version. The Ranger sprng2.0 library is compiled without -fPIC, so we make our own. Download it with "curl http://sprng.cs.fsu.edu/Version2.0/sprng2.0b.tar.gz|tar zxf -". Build the MPI version with the Intel compilers, again, using the Known Good Intel Options, "-O2 -xW -fPIC" and mpicc, mpicxx, mpif90, but add another option Fortran flags to help Fortran compatibility, "-assume 2underscores". This comes from a little bug in the SPRNG autoconf, but it only affects Fortran builds. You have to set this information in sprng2.0/make.CHOICES and sprng2.0/src/make.INTEL.

SPRNG doesn't make a shared executable. No worries. We can rebuild it as a shared library. Go to the directory of libsprng.a, and repack it with a reference to the gmp library.

ar -x libsprng.a

icc -shared -fPIC -Wl,-rpath,$TACC_GMP_LIB -Wl,-zmuldefs *.o -L${TACC_GMP_LIB} -lgmp -o libsprng.so

Were you to forget to add the reference to -lgmp, you would later see that libsprng.so cannot be loaded by R because it cannot find a function __gmp_cmp.

To build rsprng, first download the tar file. Then invoke R's installer with hints about the location of sprng. Mine looked as follows.

~/R/bin/R CMD INSTALL --configure-vars='CFLAGS="-I/opt/apps/gmp/4.2.4/include" LDFLAGS="-L/opt/apps/gmp/4.2.4/lib"' --configure-args='--with-sprng=/share/home/00933/tg459569/sprng' rsprng_1.0.tar.gz

If you get the paths correct, that should build. Now the Rmpi library wants the same attention as Rsprng. First download it. Then let R build it.

~/R/bin/R CMD INSTALL --configure-vars='CFLAGS="-O2 -xW -fPIC" LDFLAGS="-O2 -xW -fPIC"' --configure-args='--with-Rmpi-type=MPICH' Rmpi_0.5-9.tar.gz

When R installs, it will fail its first test because miprun won't work on a Ranger login node. Just go to http://math.acadiau.ca/ACMMaC/Rmpi/index.html and try the tutorial in a batch job.

HTH

Drew

A Standard Way to Use Python's Logging Module

The documentation for Python's logging module shows you its great features, but it doesn't mention standard usage if you are writing a little application or a library.

Make a separate logger for each file, and name the loggers to match the hierarchy of modules. For the file acert/hfesr/Runner.py, it starts with:

import logging
logger = logging.getLogger('acert.hfesr.Runner')
class Runner(object):
 def __init__(self):
     logger.debug('Initializing Runner')

That's quite simple. Then you can enable and disable logging by file or by module.

The second tip is that, if you have written a library, don't use logging.basicConfig() in that library because it makes logging handlers that are difficult for subsequent client applications to quiet.

HTH

/dev/null for C++ ostream

I often make C++ classes that write to some stream given to them:

Bear::Save(std::ostream& out) {
out << "Fur is " << color << std::endl;
out << "Age is " << age << std::endl;
}

Editing somebody's code today, I needed an ostream equivalent of /dev/null, some stream into which a class could write without printing anything. This can be done by creating a stream buffer that never prints.

class nullbuf : public std::basic_streambuf
{
protected:
virtual int overflow(int c) { return c; }
};

class nullstream : public std::basic_ostream > {
nullbuf _streambuf;
public:
nullstream() :
std::basic_ostream &gt(&_streambuf)
{ clear(); }

};

Using it looks like any other stream:

nullstream dev_null;
dev_null << "Nobody will ever see this.";
ostream* output = new nullstream();
(*output) << "This will be invisible.";

As usual, hope this helps.

Converting OpenDX VRML to Texture-mapped VRML

OpenDX typically writes VRML files with vertex colors, so that every vertex has an associated RGB value. Many modeling programs cannot read VRML with vertex colors, so it is useful to convert them. If you are converting a single object or a relatively simple object, there are applications to do the conversion, such as Ultimate Unwrap3D. This program examines the given Shape and figures out how to dice it evenly onto a two-dimensional texture map.

VRML from OpenDX is typically special, though, in that all of the color comes from a colormap applied to a scalar value. That means you probably started with every vertex being associated with a number between some min and max and assigned RGB values to the range of numbers. Because of this, we can use a one-dimensional texture to color a VRML from OpenDX. The process is a lot faster than unwrapping the texture, and it doesn't leave any seams.

Here's how we did it.

1. Save the VRML as grayscale.
2. Save the colormap as a jpeg or tiff (depending on what colormaps your VRML viewer can read).
3. Use a custom python script to translate each grayscale value into a u-v index into the saved colormap.

Because I didn't want to write code to read VRML, I used a shortcut. There is a program called X3D-Edit which translates VRML to X3D, which is essentially VRML in XML form. Then I used Python's ElementTree to process the XML and write a new X3D file. Then X3D-Edit or the standard XSLT will translate X3D back to VRML. It sounds complicated, but the translation from VRML to X3D and back is quite sure, and X3D is a lot easier to parse than VRML.

Powershell XML Handling for Empty nodes

Windows Powershell handles xml objects a little inconsistently. If a node is empty, then Powershell treats it as a string. If the node is non-empty, then it treats the node as an XmlNode. You can circumvent this behavior by using the Item() interface.

PS>$x=[xml]"<root/>"
PS>$x.root.GetType()

IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object

PS>$x.Item("root").GetType()

IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True False XmlElement System.Xml.XmlLinkedNode

Vista Update KB930178 Fails

An update failed on my new Vista installation with error 0xc015001a. "c015" seems to refer to Component Based Servicing (CBS), which is the tool that applied the update. 001a generally means it couldn't create or delete something. C:\Windows\WindowsUpdate.log shows more detail about the error, including the directory where it unpacked the distribution. Running Process Monitor from Sysinternals shows that TrustedInstaller.exe failed to create a file in the unpacking directory, C:\Windows\SoftwareDistribution\Download\\inst.

I tried turning off Symantec Antivirus. I tried turning off User Access Control (UAC) in the Users and Groups control panel.

When it finally worked, the system state was the following:
- Logged on as THE administrator.
- UAC was off
- Changed properties on the SoftwareDistribution\Download\ directory so that it, and its children, were no longer read only.
- applied the patch during shutdown

Drew

Fortran Memory Error

My buddy Steve just tracked down a Fortran memory error on Windows. I like recording these debugging sessions and thought to share one.

This Fortran90 application couples fluid dynamics and chemistry to do combustion. It uses the MKL version of LAPACK. It failed with a page fault, which means that there was a memory problem. How do you find it?

Fortran90 is unlikely to cause memory errors of its own accord. The language doesn't use C-style pointers, although it does add allocatable arrays to the Fortran77 standard. These arrays shouldn't be capable of corruption under normal circumstances.

The first step for Steve was to use the PageHeap tool. The old-fashioned way to use this is to use gflags.exe to turn on the PageHeap switch in the operating system. I read there is a fancier way to use it in Visual Studio 2005, but gflags.exe will suffice.

Turning on PageHeap made the program crash much sooner than before. It crashed in a particular function during exit from that function. Pseudocode for the function follows.

Sub DoWork(array,size)
If size>N
array = Allocate(4000)
end if
End Sub

This function only failed when allocate was not called. We knew that this subroutine implicitly calls deallocate when it exits, so it seemed like there might be an invalid array pointer in the heap. That means that the heap corruption discovered during the implicit deallocation was caused by stack corruption which claimed that the array had been allocated.

Steve's friend had the bright idea to use this function as a test to find where the corruption first occurred. He moved it higher and higher in the code until he found a function call to LAPACK. Looking closely at that function call, he realized that he had called LAPACK to process a matrix but had given it the wrong size for the matrix. LAPACK was overwriting past the matrix boundary. Why was it able to do this? The LAPACK libraries are Fortran77, therefore without a header file. Fortran90 was unable to check that the arguments were correct.

- Drew

Finally Fixed VTK .NET Widget Bug

I thought there was a subtle interaction between .NET and VTK that caused threading problems during user interaction. The result was that widgets did not always work. Picking would fail. The problem turned out to be that I had defined an enum for EventIds that was a copy of the VTK enum. VTK, itself, changed these values from version 5.0 to the development version, 5.x, and I was using the 5.x enum for the 5.0 code.

The fix for what I thought was a subtle bug is just to use integers instead of the EventId enum. For instance, replace EventIds.EndPickEvent with the number 9. You can look up these values in VTK\Common\vtkCommand.h.

There are no other real bugs in VTK .NET, that I know of. I could do a few things to make debugging easier and wrap HWND values, but that's about it.

That means I can release a version of VTK .NET for VTK 5.0.1. I've already integrated the new release into the patch code, tested the code for the new version, and will package it as soon as I can.

Compilation of Debugging Tools

Debugging Applications for Microsoft .NET and Microsoft Windows by Robbins has been a great, great help to me. Tonight, I used Visual Studio 2005 to compile several of the utilities supplied with the book and had to make a few changes to upgrade from Visual Studio .NET.

For CrashFinder, change the return value of OnNcHitTest to LRESULT in About.{h,cpp} and Statlink.{h,cpp}. The tricky bit is to add #define _USE_32BIT_TIME_T to stdafx.h. Then you can either modify all of the string handling routines or unselect Treat Warnings as Errors to complete the compilation.

Robbins recommends creating map files with the linker options /MAPINFO:EXPORTS and /MAPINFO:LINES. The LINES option in Visual Studio 2005's linker has been removed, but you can resurrect that information using pdb2map from the book's CD. That's the only way I know to get this information.

VTK .NET to Sourceforge

I posted VTK .NET on 23 March and have had about one hundred people come to the site each week. I can see that people download examples, so it seems to run well. I have submitted a request for a Sourceforge site, using the BSD license, which is the same that VTK uses. That should take another week or two to process.

Bugs Discovered

• I did not modify CMakeLists.txt for vtkMy or vtkLocal, which are the standard ways to wrap your own VTK C++ code for wrapper languages.


• There seems to be a problem with vtk3DWidgets. They mostly work, but a few things do not work. For example, annotatePick.cs from the examples does not notify you of new picks.

What People Want Next

• I saw a comment that the previous version of VTK .NET needed to wrap HWND types so that you could build a Windows Forms Control in C#. I've built one in managed C++, but I see the logic in the request, and I think I can add that translation to the wrapper code.


• Two people who emailed me have commented that they are working on using VTK .NET within ASP.NET. One wanted to use it to generate images on the server side. The other is interested in the more ambitious project of providing manipulable 3D graphics, something that interests me, too. There are a number of challenges to making this happen, but it would clearly be a great thing to implement.

SciPy distribution for P3 fails - what illegal instruction means

I have been trying to help someone install SciPy on our clusters. The site provides a package for P4 which works fine and one for PIII which works on my laptop but fails on our test login node. I downloaded CPU-Z to check things out, and it turns out that my Pentium M (Dothan) laptop supports MMX, SSE, and SSE2 while the dual Pentium III-S ancient server for testing supports only MMX and SSE.

As a result the provided installer for Python 2.4 and Pentium III fails for older P3 machines.

scipy-0.4.8.win32-py2.4-pentium3.exe

The test code from that provided distribution, scipy.test() will fail on older P3 chips (such as PIII-S, Tualatin) in several of the package tests with a Dr. Watson error of

Unhandled exception at 0x6988d3f7 in python.exe:
0xC000001D: Illegal instruction

The supplied binaries for ATLAS on a Windows P3 box do not have this problem. I built a running package using online instructions for a MinGW build using the precompiled ATLAS binaries. It is a quick process because you don't have to rebuild ATLAS.

I'm pretty sure we didn't just accidentally install the P4 version because I checked the show_config at the time, and we did it twice. I can't prove it because I didn't save the output. Also, the P4 version fails quickly on the P3, but the fewer tests fail when using an SSE2 P3 version on an older P3.

On the PIII-S where the install failed, the CPU information is
has_mmx has_sse is_32bit is_Intel is_PentiumIII is686
The ATLAS archdef for both the supplied package and my working build was PIII/gcc/misc and mmdef was PIII/gcc/gemm.

We run on Python 2.4.2, Windows XP Service Pack 2

The instructions that failed included cvtsi2sd, movsd, and ucomisd. I found them listed in the MMX section of the Intel assembly specification, but they are included listed only for SSE2 support. For a sense of what the code looks like, the following shows the assembly snippet.

684C5825  mov         dword ptr [esp+68h],0 
684C582D  mov         eax,dword ptr [edx] 
684C582F  mov         edx,dword ptr [esi] 
684C5831  cmp         eax,edx 
684C5833  cmovg       eax,edx 
684C5836  cvtsi2sd    xmm0,eax 
684C583A  movsd       mmword ptr [esp+14h],xmm0 
684C5840  fld         qword ptr [esp+14h] 
684C5844  mov         dword ptr [esp+5Ch],0 
684C584C  fmul        qword ptr ds:[684C5538h] 

EAX = 0000000F EBX = 684C550E ECX = 00902DD0 EDX = 0000000F 
ESI = 0021EB6C EDI = 0021EB60 EIP = 684C5836 ESP = 0021E8A4 
EBP = 00000001 EFL = 00010216

The instruction pointer is at the cvtsi2sd instruction. Normally, exceptions are thrown by the instruction before the instruction pointer, but here the exception happened just before the instruction pointer would be incremented.

Drew Dolgert

Debugging Mixed Interop Native and Managed Assemblies with Visual Studio 2005

I've been trying to track down a bug in a managed C++ wrapper around native C++ classes, and Visual Studio 2005 won't allow me to step directly from the managed code into the native code. I know it is possible, but this is the only way I see to do it:

1. Put a System.Diagnostics.Debug.Assert(false) near the start of the application.


2. Run the application and accept the option to debug it.


3. Opt to "manually choose debugger," and choose both native and managed.


4. Visual Studio 2005 then allows me to step into the native code.

Drew

unmanaged Visual C++ for Visual Studio 2005 causes (soluble) dll loading problems

Hi All,

This message is about where dlls go when they are part of “isolated assemblies.” Everyday C++ users may run into this when they move their code from a development machine to a node on a compute cluster.

1. When you copy an executable to the cluster, it now needs not only dlls but also manifest files copied with it, or we have to install them on the cluster for the users.

2. There is a common occurrence where a failure in the linker can cause an executable to fail ever to load. There is a quick fix for this.

Part I:
When compiling unmanaged visual C++ applications in VS2005, you have to pay attention to how you distribute the dlls. Normally, you just put Dlls beside the exe. That isn’t working for some good reasons. I’m going to give you an outline here of where the bodies lie, trying to show you pertinent directories, tools, and project settings.

Google keywords: Isolated applications, side-by-side assemblies, winsxs
Web pages:
About isolated apps and assemblies
http://msdn2.microsoft.com/en-us/library/ms235342(en-US,VS.80).aspx
blog with details on how to do installation with isolated apps
http://blogs.msdn.com/nikolad/
Windows Installer XML – use xml file to create an msi.
http://sourceforge.net/projects/wix

There is a section in VS under Linker->Manifests that says you can
- embed manifest – yes/no
- allow isolation – yes/no

Visual Studio now distributes the CRT and debug CRT and versions of ATL and MFC libraries in VS
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86
C:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86

Here you find the directory Microsoft.VC80.DebugCRT\ with the files
- Microsoft.VC80.DebugCRT.manifest
- msvcm80d.dll
- msvcp80d.dll
- msvcr80d.dll

Executables, under various conditions, are supposed to be able to find dlls in various directories if you put the manifest with them
- C:\Windows\WinSXS
- <appdirectory>
- <appdirectory>\<appname>.exe.local
- <appdirectory>\<manifestname>

Part II: The Common Deal-breaker: Oldnames.lib

When you compile code which links to libraries using older, deprecated methods, the linker finds those methods in an implicit library called Oldnames.lib. Because of a flaw in the linker, any time it pulls in oldnames.lib, it will also pull in a copy of the wrong CRT. That is, if you link against the debug CRT, it will pull in the release CRT, and vice versa. This wouldn’t normally cause the executable to fail to run, except that the linker includes only the correct assembly. For instance, when linking against the debug CRT, the following manifest is included in the executable, even though the linker mistakenly linked to the runtime CRT, as well.


<assembly xmlns="'urn:schemas-microsoft-com:asm.v1'" manifestversion="'1.0'">
<dependency>
<dependentassembly>
<assemblyidentity type="'win32'" name="'Microsoft.VC80.DebugCRT'" version="'8.0.50608.0'" processorarchitecture="'x86'" publickeytoken="'1fc8b3b9a1e18e3b'">
</dependentassembly>
</dependency>
</assembly>

The solution is to tell the linker to ignore the other CRT. In other words, if you link with msvcrtd.lib, you have to explicitly tell the linker to ignore msvcrt.lib, and vice versa. That makes the linker think longer about where it can find the references it needs, and it comes back around to the correct library.

Mind that Microsoft would not consider this problem a linker flaw because I have only seen it happen when linking to libraries older than my current version of Visual Studio, and linking Visual Studio 2005 projects to those of Visual Studio 2003 or Visual Studio 6 is not supported. This is likely confounded with the fact that I am linking release and debug always to a release library, which is not supported. Does any company really distribute their development libraries as MT, MD, MTd and MDd? I've only seen VRCO do this.

At this point, I’ve also created an installer for the C runtimes, as described in the blog link above, so that’s what is loading. I just run vccrt.msi, then my application runs. I used this tool called WIX to install it. It’s a bit of open source from Microsoft. The project doesn't appear to be under development any longer, but it's still working for now.

Drew

running openmp on cluster requires per-application configuration file

John, Dave, and I were trying to run a Visual Studio 2005 OpenMP code on cluster nodes. We ran into an extra wrinkle with the isolated assembly for Visual Studio’s OpenMP. In addition, a curiously low-tech bug in Visual Studio kept us from discovering we had the correct solution.

Typical deployment of isolated assemblies on a cluster node
We have already covered the typical story for isolated assemblies. If an application uses a dll which was compiled as an isolated assembly, then the application has to contain a manifest which specifies those assemblies. Visual Studio automatically embeds that manifest in the application. When you deploy that application to a new machine, Microsoft recommends that you use an installer to install that assembly as a shared assembly, meaning that the installer places the assembly in the WinSxS folder in the Windows folder, which functions like a GAC. Visual Studio even includes a vcredist.exe program to install all of the release versions of Visual Studio isolated assemblies into the WinSxS folder.

Because we are running on cluster nodes, we want to know how to deploy those isolated assemblies, instead, as private assemblies. This is usually a simple matter. You find directory for the isolated assembly, such as Microsoft.VC80.DebugCRT, in C:\Program Files\Visual Studio 8\VC\redist\Debug_NonRedist\x86. Copy the whole directory to the same directory as your executable on the cluster node, and everything should work.

By the way, Dave installed the redistributable, release version, isolated assemblies on one of the clusters. We have to figure out whether we will install all Visual Studio assemblies on the clusters for the users. The problem will still exist for other isolated assemblies, although we don’t, at this point, know of any coming from companies other than Microsoft or products other than Visual Studio.

How OpenMP requires another step to deploy

When you try the above technique for OpenMP, the executable still fails to find the assembly on the cluster node. When Visual Studio compiles your OpenMP program, it embeds a manifest file that refers to version 8.0.50608.0 of the OpenMP assembly, but the actual assembly is version is 8.0.50727.42. Why would this work on your machine? It works because your computer has a machine-level policy, sitting in %windows%\WinSxS\Policies, which states that, if any application asks for version 8.0.50608.0, it’s okay to give them 8.0.50727.42.

The version mismatch between the distributed assembly and the assembly required by the compiler is a known problem. It happens because different parts of Visual Studio are frozen at differnt times before delivery. What we have to do to make this run on the cluster is to deploy that same policy as an application configuration file.

Application configuration files for native application files are very similar to those for managed files. If your program is myprog.exe, you make a text file, with UTF-8 encoding (with or without a byte-order mark), called myprog.exe.config. In it, you redirect the program’s binding to the newer version of the debug OpenMP assembly. Note that, when you identify the DebugOpenMP assembly, you leave out the version attribute because you will specify it in the bindingRedirect node.

<span style="color:#3333ff;"><configuration>
<windows>
<assemblybinding xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyidentity name="myprog.exe" processorarchitecture="x86" version="1.0.0.1" type="win32">
<dependentassembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.DebugOpenMP"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"/>
<bindingredirect oldversion="8.0.50608.0" newversion="8.0.50727.42">
</dependentassembly>
</assemblybinding>
</windows>
</configuration>
</span>

If we had deployed the OpenMP assembly to WinSxS, so that it was a shared assembly, I think that there would have been a machine-level policy to take care of the version mismatch. As is, we had to make this file for ourselves and deploy it in the same directory as myprog.exe.

How a little bug made this hard to figure out
Yesterday morning, we had figured out that there was a version mismatch and that an application configuration file was necessary. We had copied the debug OpenMP assembly directory into the same directory as our application, but nothing worked. After five hours, we noticed that the debug OpenMP assembly directory was called Micrsoroft.VC80.DebugOpenMP. If you look in your Studio 2005 VC\Debug_NonRedist\x86 directory, you’ll find that the directory name is wrong.

Drew Dolgert

Attempting to contribute to VTK open source

We use the Visualization Toolkit a lot around here to make standalone applications or to use in our CAVE. I usually write the applications in Python using wxPython, but sometimes the client needs an installer and a regular windows application, so I like to use Windows Forms in that case. To that end, I normally wrap VTK code in managed C++. There were, and still are, compiled wrappers provided by a group in Slovenia, but this seems to have been a masters thesis, and they never released the code.

It seemed like a great chance to contribute to the project, so I've created wrappers that could fold into the source tree.

• Managed C++ wrappers for VTK.
• Allow use in C#, managed C++, VB, and others.
• .NET 2.0 only, meaning Visual Studio 2005.
• Builds within the typical CMake build system for VTK.
• Includes a .NET Windows Forms Control for drag-and-drop in Visual Studio designer.

We'll have to see how successful these are. Because the CMake build system does not handle managed C++ projects, the build isn't entirely hands-free. Just before hitting Build in Visual Studio, the user has to execute a macro to convert the projects to managed code. That problem means this wrapper couldn't be built in nightly dashboard tests. I'd be willing to extend CMake to handle managed projects if that's what it takes.

Drew Dolgert

Welcome

I work on scientific simulations and visualization. Some of my friends plan to chip in. We are driven to start this blog by having spent too much time solving technical problems we are sure others have faced. Welcome.