[CMake] CMake/CPack /w BundleUtilities on Windows with NSIS fails

[Bill Somerville]

On 13/02/2014 18:10, Bill Somerville wrote:
> Hi,
>
> I have a CMake script that runs on Windows with MinGW Makefiles that 
> builds the install target OK. It is a Qt GUI application and uses 
> BundleUtilities::fixup_bundle to pull in and link/rpath prerequisites.
>
> When I build the package target with an NSIS packager it looks like 
> the fixup_bundle stage breaks in some way. I get several of the 
> following message box pop up in the install phase.
>
> ---------------------------
> link.exe - System Error
> ---------------------------
> The program can't start because mspdb80.dll is missing from your 
> computer. Try reinstalling the program to fix this problem.
> ---------------------------
> OK
> ---------------------------
>
> If I dismiss them all the build finishes without error but none of the 
> prerequisite libraries or Qt plugins are in the install kit (they go 
> in /w the install target as expected).
>
> I suspect a PATH problem but have no idea how to debug this further.
OK, so I have progressed a bit. This is something to do with the MS tool 
dumpbin which is used to analyse binaries for prerequisites as part of 
BundleUtilities::fixup_bundle.

It looks for a suitable tool and on Windows prefers dumpbin over MinGW 
objdump. In my case even though I am using MinGW for builds, I have MSVC 
installed too.

So for the install target dumpbin seems to work ok to analyse the 
binaries. I still don't understand why the package target goes wrong as 
described in the OP.

Looking at the GetPrerequisites.cmake module I see that I can force the 
choice of binary analysis tool by defining the variable gp_tool. So I 
define it to "objdump" before executing fixup_bundle and it seems to 
work. the only problem is that it takes about 15 minutes (on i7 
processor!) to complete a package generation that takes less than a 
minute when dumpbin is used :(

I would really like to know why it is going wrong with dumpbin in 
package generation because using objtool is too slow!
>
> TIA
> Bill.
Regards
Bill.