I’m not sure exactly why this happened. Yesterday I was trying to do a batch build for one of our most complex components – our Barcode Scanner Hardware Abstraction Layer (ScanHAL). This is a set of libraries which implement the same interface, to make our applications hardware independent with respect to the barcode scanner, making it possible to run more-or-less seamlessly on HHP Dolphin, Intermec and Symbol hardware, as well as on handhelds with no built-in barcode scanner (there’s a stub implementation). The clever bit (heh) is that all of the different libraries are included in the same CAB package, with a setup DLL which probes to decide which library is correct for the handheld it’s running on.
Anyway, the release process involves a batch build of everything, which rebuilds everything from source. For historical reasons the projects still support Pocket PC 2000, which ran on a bunch of different processor types (ARM, MIPS, SH3, x86 emulation). The build process currently builds both debug and release builds. For one particular customer, we made available a release build with debugging information, stripped of private symbol information using a tool by John Robbins called PrivateStrip – this means that they can tell us which function the program crashed on, if it does, but can’t easily disassemble the library. So in all there are about 20 different configurations of different libraries that need to be built.
Unfortunately since Wintellect reorganised their website, PrivateStrip is no longer available. I hope they’ll reinstate it.
Yesterday, the linker was repeatedly hanging in the last stage of building DLLs: it had just output the message about building the .LIB and .EXP files, but wasn’t completing the build. On a couple of occasions it did this on the last DLL – but it wasn’t consistently on any given DLL. My work machine is hyperthreading-capable, and this was happening with HT enabled. Turning HT off enabled me to complete the build.
I don’t know whether this would also happen on a dual-core or other multiprocessor machine.
You might need to be careful if you’re using older tools (eVC 3.0 and 4.0 both use modified versions of Visual C++ 6.0’s LINK.EXE) on a computer with more than one logical or physical processor.