vs2017 getAllPages() exception

[logan-x]

I copied the qpdf.cc file in my test project,Then input the command line：d:\2.pdf d:\out.pdf --pages d:\2.pdf 8-15 --
When I'm running here ： orig_pages(qpdf->getAllPages())，there is an exception.
And then I tested it, and every time I called "qpdf->getAllPages()", it triggered an exception.

Oddly enough, this is not the case when I run the command line directly.
qpdf d:\2.pdf d:\out.pdf --pages d:\2.pdf 8-15 --

in debug mode.

[mtoftdal]

This is probably caused by an STL structure being passed between modules using two different versions of C runtime. The getAllPages method returns an STL vector created in you QPDF dll and it is used in your example application. My guess is that these two modules, the dll and the program, are using two different versions of C runtime -- that is, they are built with different versions of Visual Studio.
I think many other libraries avoid using STL in their API. But for the libraries that do use STL, you need to make sure that the library is compiled with the same Visual Studio version as the modules that use it (or if possible just not use the API parts that use STL).
What is your view on this, @jberkenbilt ? Have you considered removing STL from the API or maybe provide an alternative page API?
See also discussion here, for instance: https://social.msdn.microsoft.com/Forums/vstudio/en-US/8f2843ae-010d-4440-ad1b-9f021bb74c2e/stl-compatibility-across-different-versions-of-crt?forum=vcgeneral .

[jberkenbilt]

Removing STL from qpdf's interface is a non-starter. It's a deep part of the interface. I'm not really a Windows developer, but I can look at the link you provided. People are always free to download qpdf and build from source. If there's anything I can update in the docs or do differently about how I build or distribute the msvc binaries, I'm certainly happy to consider, but STL is not going anywhere.

[mtoftdal]

That's totally fine with me, @jberkenbilt. :-) I was just curious to know if you had considered this.
As far as I know this is not just a Windows problem, though it's much more obvious there. Other platforms can have incompatible STL libraries too, libstdc++ and stdc++ on Mac and Linux are probably the most relevant here.

[mtoftdal]

...and for the second part of your comment, I don't think you can address this in the build. But it might be helpful to state in the docs that the same MSVC version must be used for building the DLL and for building the program using the DLL (at least if the STL part of the API is going to be used). And for the current pre-built DLLs that requires VS 2015 as far as I can tell.

[alexis-idigo]

I'm facing the same issue and would prefer to avoid rebuilding qpdf lib, at least at this stage of evaluating/writing sample programs. I will be glad to do it later [aka updatee for Visual Studio 2018] when I will move to use this lib in an actual product ;-)

As a suggested simple solution, would it be possible to reference/include MSVC DLLs used for the qpdf lib that is included in the release?

[alexis-idigo]

btw, I installed toolset 140 and got same issue as originally reported.

Please note I think qpdf is the best tool ever for manipulating PDF thus my push to be able to use it ;-)

[alexis-idigo]

More precisely, both using toolset 140 and 141, I can't link using the non-debug multi-threaded LL [since I expect as indicated in the documnetaion that qpdf lib would use the release version] due to these errors:
pdf-count-strings.obj : error LNK2019: unresolved external symbol __imp__invalid_parameter referenced in function "public: class QPDFPageObjectHelper const & __cdecl std::_Vector_const_iterator<class std::_Vector_val<struct std::_Simple_types > >::operator*(void)const " (??D?$_Vector_const_iterator@V?$_Vector_val@U?$_Simple_types@VQPDFPageObjectHelper@@@std@@@std@@@std@@QEBAAEBVQPDFPageObjectHelper@@xz)
pdf-count-strings.obj : error LNK2019: unresolved external symbol __imp__CrtDbgReportW referenced in function "public: class QPDFPageObjectHelper const & __cdecl std::_Vector_const_iterator<class std::_Vector_val<struct std::_Simple_types > >::operator*(void)const " (??D?$_Vector_const_iterator@V?$_Vector_val@U?$_Simple_types@VQPDFPageObjectHelper@@@std@@@std@@@std@@QEBAAEBVQPDFPageObjectHelper@@xz)

[alexis-idigo]

I moved on and tried to build the library.
Followed instructions at "https://github.com/qpdf/qpdf/edit/master/README-windows.md"
Successful until I reached thsi step:
Configure and build as follows:

./config-msvc
make

For which I got:
alexis@Butterfly MINGW64 ~

./config-msvc

-bash: ./config-msvc: No such file or directory

Hoping to get some help ;-)

[alexis-idigo]

Update: I managed to rebuild qpdf and qpfd lib using VS2015 x64
I just had to:

• move the external libs inside a subfolder of qpdf-master folder named "external-libs".
• set the path into VS console first to qpdf-master folder before launching MSYS2 console
  Except for these minor installation details, I did not have to edit any file and qpdf seems to be working based on simple test

I will now:

• try to build and run the full test suite on this first
• redo the build with VS2017

Before moving on to change the config to also build a debug version of the lib ["qpdfd.lib"?] as part of the process.

Will keep posted in case this is useful for others...

[alexis-idigo]

Just wanted to give a quick update: I managed to build libqpdf for MSVC 2015 in debug mode and seems to be working properly on a few examples ;-)

I also run the test suite [without image comparison] and just get 4 fails, seemed related to encryption:
[...]
qpdf 1495 (encrypt R3,V2,U=view,O=master) ... FAILED
qpdf 1496 (check /P) ... FAILED
[...]
qpdf 1500 (check /P) ... FAILED
qpdf 1690 (copy of unfilterable with crypt) ... FAILED

I will continue and proceed with:

• MSVC 2017 support
• Image Comparison test suite

Hopefully I can reach something good enough in the next few days to put a pull request ;-)
Changes up to now are minor and mostly related to the build mechanism to support various platforms [x86, x64] without any warning and mode [debug/release] that I should complement to support various tool chains [v140, v141].

I'm lacking experience with make and related tools so taking slightly longer and will probably need some "tolerance" and help from the experienced people here to make my pull request as clean as they would like it to be ;-)

[alexis-idigo]

PS, when I said "I managed to build libqpdf for MSVC 2015" it was actually using MSVC 2017 but with proect set up to use vc140 tool chain so that's a really good sign imho

[jberkenbilt]

@alexis-idigo Thanks for your work on this. I'm happy to tweak whatever you come up with to handle make issues or other things. Mostly as long as what you produce doesn't break other stuff, I'm inclined to take it. Anything that helps with building qpdf on multiple environments is appreciated. There are some other pull requests I have yet to study that get qpdf working in some other compilers, and I have one commercial user who builds qpdf on over 100 permutations of versions of compilers and operating systems with good success using his own build system. As such, I suspect the issues to be limited to build and not qpdf's actual code. Anyway, thanks for your work and continual updates to this ticket with your progress. Sorry I am not able to provide direct assistance.

[alexis-idigo]

@jberkenbilt Thanks for your kind comments!
I'm hoping to not only make it work on various MSVG but also to fix the FAILED test, and come with changes that would not break the build.
I agree with you, should be mostly in the build, except for the FAILED, I found some strange and presumably erroneous use of char* vs unicode string in calling Windows API and I suspect they are the reasons.
Will submit a clean pull request when I'm ready. For now directly patching my local branch using a MSVC project with all files statically linked for faster test ;-)

[jberkenbilt]

@alexis-idigo I don't know if this is still an issue for you, but recent qpdf releases have made some improvements to Unicode handling on Windows, and current unreleased master has a number of other fixes around casting. If you're subscribed to the qpdf-annonce list, I'll be announcing an alpha of qpdf 9 for testing soon. If this is no longer an issue, we can close this, or we can close it if you're going to do other investigation and create a new issue or pull request.

[drcdr]

As I commented in #427, I was able to get Debug mode to work OK (using QPDF binaries) by changing the Runtime Library option, from the Debug default [Multi-threaded Debug DLL (/MDd)] to the Release default [Multi-threaded DLL (/MD)]. As I'm using QPDF in a DLL, I also had to change to /MD in my application, since I was passing strings from the application to the DLL.

[fredemmott]

So, fundamental problem is that with MSVC, there are four important C++ runtimes, which are incompatible:

• single-threaded, debug
• single-threaded, release
• multi-threaded, debug
• multi-threaded, release

qpdf appears to be built with the multi-threaded release - if you use any other one, many things are incompatible, including std::vector. QPDF's windows zip also includes some runtime DLLs; if those are needed, it would be good to upgrade to the UCRT - then, there is no need to include them, and VS2015-VS2022 can all use the same version (but still need the same threading + debug/release variant)

There's historically two approaches:

• always build your project and all your other dependencies with multi-threaded, release
• build yourself with MSVC + msys in the configuration you want

Option 1 makes many issues (whether in qpdf usage or not) much harder to debug; option 2 is hard to integrate with other environments.

So, I took a look at building just libqpdf as a static library with cmake - my project already uses cmake, but for projects that don't use cmake, it should be easier to integrate than msys as visual studio nowadays includes cmake.

Turns out it's pretty straightforward: https://github.com/fredemmott/OpenKneeboard/blob/683801599e507e9e47aa13f71758c99ee0efa6c0/third-party/qpdf.cmake - include that in your cmake project and depend on the qpdf target. It will use the same release/debug and single/multithreaded runtime as the rest of your project.

If you're not using cmake in your project, you need a small top-level wrapper cmake file, and set MSVC_RUNTIME_LIBRARY and CMAKE_BUILD_TYPE to match the configuration you want.

You also need qpdf-config.h.in from the same directory, and zlib and libjpegTurbo targets defined - likely also want to grab libjpeg-turbo.cmake and zlib.cmake from the same place.

Caveats:

• only tested with 64-bit Visual Studio 2022
• always uses native crypto. See QPDF's readme for downsides. This is fine for me as all I care about is extracting outlines for unencrypted and trusted PDFs, your use case may differ
• always builds as a static library

If the maintainer would be interested in merging CMake support for libqpdf, I can look at addressing these limitations and making a PR (including extending to linux and macos).

[jberkenbilt]

@fredemmott I have considered switching over to cmake and might be interested in looking into what it would take. I do not know cmake, but I have extensive build experience having actually built and maintained a build system about 15 years ago, so I don't think I'll have any trouble understanding it. I'm not really comfortable with Windows toolchains. What qpdf has is something I worked out over 10 years ago and have kept working, but switching over to cmake would probably be a good thing. If you're interested in helping with getting qpdf integrated with cmake, let's create a separate issue (or discussion) and work it out before going to a pull request. Note that qpdf 10.6, just released today, now invokes a Python script to do some code generation. I ship the generated files, and the code generator is only run when --enable-maintainer-mode is passed to ./configure, but I would need that to work. There is also a lot of custom stuff in my autoconf setup. qpdf has its own make system (based on my previous build work). It uses autoconf but not the whole autotools toolchain.

[jberkenbilt]

@fredemmott I've pretty much decided to switch the build over to cmake for qpdf 11. It'll be a few months, but I'm motivated by this, the need to upgrade to a newer Windows toolchain again, and some issues with rpath on the Linux build. cmake has definitely gained a lot of popularity, and I'd rather delegate to them when it comes to keeping up with all the different options for building on different platforms. A lot of the stuff in autoconf is probably overcome by events with the decision to standardize on C++14, so it will give me a chance to take a top-to-bottom look on the whole build process. The build is actually quite straightforward....

[jberkenbilt]

@fredemmott I'm not quite there yet, but I've started working on getting qpdf's build working with cmake. I have pretty deep build experience in the UNIX world, but I'm new to cmake and I have no IDE development experience in Windows. Would you be willing to help out when it comes to testing the cmake in your Windows environment? There are lots of things in cmake that appear to be there to support IDEs, and I would have no way to actually notice if I got them wrong. If you're willing, then I will open a "discussion" issue and tag you on it when I get a little closer. My first goal is to get the cmake build to have parity with the existing autoconf-based build on Linux, then mac, then Windows from the CLI. Then I'll be ready for help. I might be ready for help during the Windows/CLI part. I'm chipping away at this in my available time. It will probably be a few weeks before I've gotten that far, and it will probably be a few months before an official qpdf release uses cmake. Please let me know if you're willing to help out. If so, great. If not, I'll see if I can find someone who is a Windows developer who might be able to help.

[fredemmott]

Sure, though I've actually never needed any of the IDE-specific options in CMake; though, some MSVC options refer to the compiler, not the IDE. My usual workflow is VSCode with the CMake extension - no special support in the CMake files - and in my cross-platform projects this works pretty much identically between Windows, MacOS, and Linux.

Microsoft also make a Windows 11 development VM image available at no cost at https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/

[fredemmott]

Also I should note that using file(GLOB and file(GLOB_RECURSE like I did is pretty strongly discouraged: it's highly recommended to explicitly list the source files. I used glob as I just wanted to unblock my stuff quickly, rather than make a reliable + maintainable build system.

[jberkenbilt]

Thanks for the replies. I would definitely not use globs. I have studied several projects that use cmake and have a pretty good idea now. The main thing is that, with no real development experience inside an IDE, I don't really know what people expect. I guess I'll push something out there and wait for people to make suggestions. :-) Whatever I do is going to be better than what's there now.

[fengshaoxie]

getAllPages creash in VS2019 in debug mode, in release mode is normal , is need build dll with debug。

[jberkenbilt]

qpdf 11 will be built with cmake. I intend to distribute debug DLLs or at least make it easy for people to build their own. Most likely I will distribute them unless there is some reason that I can't.

[jberkenbilt]

Hey Windows people....up to now, qpdf has always renamed its DLL to be like qpdf28.dll while the import library is just qpdf.lib. I did this to try to be a little more like ELF shared libraries which have SONAME. Based on everything I can find, this is just something Windows packages don't typically do. While I could probably hack something up in cmake to make this work (like renaming the import library at install time), I think I should probably just drop it and let the dll simply be called qpdf.dll.

Does anyone who is following this ticket think see any reason not to just let qpdf.dll just be qpdf.dll?

[fredemmott]

On windows, I've only really seen SONAME-like filenames from projects that were primarily developed for *nix; foo.dll and foo.lib (and the corresponding food.dll and food.lib for debug builds) are much more common.

That said, I don't think it matters hugely either way:

• if users are linking statically, it doesn't matter at all
• if they're dynamically linking and distributing as an MSIX or AppX (recommended by Microsoft, but honestly a little half-baked outside of the Windows store), DLLs are either bundled with the package, or specified as a package dependency with version information. Package can either be bundled, or fetched from the MS store, and multiple versions can be installed simultaneously. There's no need for SO versioning.
• if they're dynamically linking and distributing as a .zip, .msi, .exe installer etc, by far the most common approach is to dump the dependency .dll's in the same directory as the application exes, so again, unneeded. Actually installing dependency dlls (except for things like VC++ runtimes etc) system-wide is relatively rare nowadays."

Edit: also feels similar on MacOS, except when using homebrew - everything's in the Foo.app directory. Homebrew emulates the linux 'global shared libraries' model. Windows technically has that too, but it's not broadly used because of the 'dll hell' fun prior to MS introducing versioning solutions, and storage/bandwidth getting cheaper.

[jberkenbilt]

@fredemmott Thanks again for your input. I think I'll just do what cmake does by default. The fact that the cmake docs are completely silent on this and that searching online for information comes up empty just reinforces what you're already saying. For people who dynamically load the DLL at runtime, a non-versioned DLL will probably be easier anyway. Thanks!

[jberkenbilt]

At this point, on a private branch, I have a cmake configuration that I can use to get a fully passing test suite for qpdf on MSVC64 "Release" configuration. There is more work to do before I'm done, but I'm over the hump. (I'm having to chip away at this in my "spare time".) @fredemmott Although my solution is quite different from the one you linked to above, I read through your stuff carefully and definitely found it helpful as I was coming up to speed.

Soon I will attempt to do the EXPORT bit and hope to come up with something that a cmake-based project can consume. The only artifact in qpdf that anyone would depend on from a cmake standpoint is just the library itself, but maybe I can come up with something where I can have Release/Debug configurations and potentially static/dynamic runtimes. Last I recall, there are licensing restrictions against distributing debug versions of stuff, though I could be out of date on that.

Do you think it's good practice to distribute debug versions in addition to release versions, or is it sufficient for qpdf to be a good cmake citizen for people who want to debug with it to just build it themselves? As far as I can see, this thing of not being able to link a Release library against a Debug build is limited to MSVC. The mingw builds don't appear to have this issue.

If I can make it work and it's allowed by the licensing, my intention would be for the msvc qpdf binary distributions to include Release with static and dynamic runtimes and debug with dynamic runtime only. My reasoning is that C++ developers don't need static runtime, and people who are pulling in qpdf.dll from other languages at runtime would probably enjoy the static runtime since there are fewer DLLs to manage, but I'm kind of guessing since I'm not a native Windows person.

[fredemmott]

Although my solution is quite different from the one you linked to above

This is probably a good thing :p

where I can have Release/Debug configuration

Configure-time: ${CMAKE_BUILD_TYPE}
Build-time: $<CONFIG>

I dislike that they don't have the same name, but the difference matters:

• when CMake is generating Makefiles, CMAKE_BUILD_TYPE is baked into the Makefile - you need to re-run cmake if you change the build type, and it'll get baked into the makefile
• when CMake is generating some other forms, including msbuild/visual studio, the generated files can be used to build all the configurations - CMAKE_BUILD_TYPE is largely irrelevant and doesn't end up in them. If CMake is generating/calling something, you need the $<> syntax + names (https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html)

Also, I recommend RelWithDebInfo instead of Release - even if users don't ship them with them their applications, having the debug symbols available somewhere for tagged releases an be really handy. In the case of Windows, this is .pdb files. RelWithDebInfo are ABI-compatible with Release libraries.

potentially static/dynamic runtimes

For something like this, I think it's most common to always build both - with something like:

option(BUILD_SHARED ON)
option(BUILD_STATIC ON)

if(BUILD_SHARED)
  add_library(foo SHARED ${SOURCES})
endif()
if(BUILD_STATIC)
  add_library(foo-static STATIC ${SOURCES})
endif()

Another common approach (that needs two builds) is:

set(LIBRARY_BUILD_MODE SHARED)
option(BUILD_STATIC OFF)
if(BUILD_STATIC)
  set(LIBRARY_BUILD_MODE STATIC)
endif()
add_library(foo "${LIBRARY_BUILD_MODE}" ${SOURCES})

Do you think it's good practice to distribute debug versions in addition to release versions, or is it sufficient for qpdf to be a good cmake citizen for people who want to debug with it to just build it themselves?

It's sufficient - debug builds are definitely convenient for those not using cmake though.

The 'best' way for all-in Visual Studio users is probably to publish a nuget package, but I'm not familiar with that.

As far as I can see, this thing of not being able to link a Release library against a Debug build is limited to MSVC. The mingw builds don't appear to have this issue.

I'm being a bit pedantic here: the issue is in Microsoft's C++ standard library. There's the same problems when using clang-cl (clang's MSVC-compatibility mode). mingw doesn't use the MS standard library

As a tangent: if you encounter template or C++20 concept issues on windows, I strongly recommend setting up a CI config with clang-cl. MSVC has a tendency to just fail with something along the lines of no match, whereas clang gives genuinely excellent error messages.

licensing

:/

I've noticed that microsoft don't distribute the debug libraries outside of the SDK. I've personally steered away from distributing debug builds that are statically linked against the C++ runtime, but honestly I don't know if that's enough and I need to dig into it more.

[jberkenbilt]

Regarding shared and static libraries, I already build with both. This is static vs. dynamic runtime, which is different -- /MD vs. /MT. I haven't tried /MT, but I think it just links in all the MS*.dll files so you don't have to redistribute them or have them in the same directory. Not something you would usually want to do since the MS runtime libraries are redistributable, but handy for people who want just one DLL to embed with their stuff.

Actually, what I have is an OBJECT library which, if you're only building shared uses position-independent code, and if you're building static (with or without shared), then not. Then the static and/or shared library as appropriate use the object library as do the library test drivers. This solves two problems with the current build: it is possible to do a single compilation if you enable only shared or static, and it's possible for the library internal tests to link statically even when static libraries are disabled, which means no more DLL exports of private interfaces for testing. It was quite easy to get this to work with cmake, and while I could have gotten to work with my home-grown Makefile system, it's nice not to have it.

Another nice thing about my current cmake setup is that it's actually possible to build qpdf without msys installed, though it is still required to run its tests, and I have no intention of changing that -- it would be a massive undertaking with no upside.

I'm on C++14 for now, so C++20 issues won't be a problem for me for a while. qpdf tries to support older compilers for a while.

RelWithDebInfo is good and matches what the current builds are as well as the default configuration for the Linux builds, so I'll stick with that.

I've worked out all the issues with ${CMAKE_BUILD_TYPE}, $, ${CMAKE_CFG_INTDIR}, etc. One thing that helps a lot for testing is $<TARGET_FILE_DIR:tgt>.

This is all good information. Thanks!

[fredemmott]

without msys installed, though it is still required to run its tests, and I have no intention of changing that -- it would be a massive undertaking with no upside.

If this is mostly about needing bash, coreutils, awk etc, https://docs.microsoft.com/en-us/windows/wsl/about is the more common way to do this on modern windows - if that's all, perhaps adding a cmake variable to specify 'bash path'? Setting it to wsl (e.g. wsl foo/bar.sh) is enough for most cases.

The wsl environment is pretty powerful: it's basically a full ubuntu environment that is able to execute both ELF and PE (win32) executables, pipe between them, etc. ./foo.exe | myscript.sh | ./my-elf-executable all works fine.

[jberkenbilt]

wsl doesn't work very well for native builds; it's much better for cross compilation. There's a good writeup about it here: https://www.msys2.org/docs/what-is-msys2/

My windows dev environment has wsl on it, and I use it for most of my editing, running git, etc., but for running qpdf's test suite, msys works better the shell can run windows commands natively and follow all the Windows sematics (like qpdf instead of qpdf.exe, etc.) It was my hope to use wsl instead of msys, but wsl is just not designed to be a UNIX-like shell for native Windows. It's designed to be a full Linux environment embedded in Windows.

Also, wsl2 doesn't currently work in virtualbox. I don't have a Windows system. I'm testing on an ec2 instance right now, but my default Windows dev environment is a virtualbox vm. I believe you can run wsl2 in vmware workstation, but for my use, there's no point in buying a license. (I can do it on my work laptop.)

Also using cmake in wsl to build with mingw is unnatural, and I'd rather do a native build than a cross-compiled build.

[fredemmott]

Doesn't sound like it would be a good fit, but to clarify: I didn't mean to build using WSL - just to use it to aid running tests. I definitely wouldn't advocate mixing it with mingw.

[jberkenbilt]

For anyone watching, on my private branch, I have a cmake build working that passes all tests on all four Windows permutations currently supported including large file tests on 32-bit platforms. I am at parity with the old build but still haven't added cmake export (should be half an hour's work) plus I have some doc cleanup and other stuff. My current intention is

• Continue to rename the DLL as before, so qpdf 11 will be qpdf29.dll with libqpdf.a/qpdf.lib as the import library. This will be consistent with how qpdf has always been. I have found that there are other popular libraries that have similar schemes, and I am firm in my belief that it is beneficial to do this.
• I will probably use a Release build for msvc and a RelWithDebInfo build for mingw and Linux. While RelWithDebInfo is link-compatible with Release, you get lots of linker warnings, and releasing Release builds seems customary for msvc while RelWithDebInfo is consistent with the norm in the gcc world.
• It is trivial for me to use cpack to make a NSIS installer (already done and tested), so qpdf 11 will have a traditional installer executable in addition to a zip-based distribution.

I have learned a lot about cmake during this exercise, and I've been quite impressed with the tool. I had implemented lots of hairy make code to get the qpdf build to behave the way I wanted it, but with cmake, my workarounds fit neatly into established patterns. A number of things work better, and I have been able to eliminate a few unfortunate hacks in the qpdf build. This will be a big improvement. I have no further questions at this time -- I have a clear path to the finish line.

@fredemmott Thanks especially to you for weighing in and providing your input. I have 10.6.3 (still old build system) sitting ready to release. The release announcement will mention the cmake work and offer people a chance to pretest when I'm ready. What I'll do is to create a discussion issue and reference it in the release announcement. To avoid spamming recipients of this issue, I won't mention this from there or the other way around, but if anyone wants to be specifically tagged on that issue, just reply here. Thanks!

I will leave this bug open until we know for sure whether the cmake-based build solves the problem or if we have confirmed that it is a release/debug issue.

[jberkenbilt]

I released a new prerelease built with cmake: https://github.com/qpdf/qpdf/releases/tag/release-qpdf-10.6.3.0cmake1

I'd be curious to know whether this helps. Any other feedback would be welcome. I created a discussion ticket which you can find a link to from the release page. I won't put it here because I don't want to link this issue with the discussion.

[jberkenbilt]

Closing for lack of activity.