[CMake] BundleUtilities not working

Bill Somerville bill at classdesign.com
Tue Jul 28 11:32:40 EDT 2015


On 28/07/2015 16:03, Bill Hoffman wrote:
Hi Bill,
> On 7/28/2015 8:59 AM, Bill Somerville wrote:
>> Hi,
>>
>> I am suffering issues with BundleUtilities fixup_bundle() when used on
>> Windows with MinGW. The issue is because the underlying GetPrerequisites
>> module uses the MS dumpbin.exe utility to find dependent libraries of
>> executables. This is a problem because it crashes on many libraries and
>> executables from later MinGW tools, for example the GNU Fortran library
>> libgfortran-3.dll. I believe the crash is due to the DLL having no 
>> symbols.
>>
>> The problem is exacerbated by GetPrequisites having very little error
>> checking so it silently fails and doesn't install the dependent 
>> libraries.
>>
>> GetPrerequisites can use objdump if dumpbin is not available but this
>> has another issue. The output from 'objdump -p <executable>' can be very
>> long, over 10000+ lines for a large Qt library for example, and this
>> causes GetPrerequsites to run exceedingly slowly as it uses
>> execute_process() to capture the output into a CMake variable then
>> parses it with string(REGEX REPLACE ...) and a loop doing an if(...
>> MATCHES <regexp>) on every line.
>>
>> So I have a choice of broken or too slow for practical use :(
>>
>> Is BundleUtilities.cmake and GetPrerequisites.cmake maintained, if so
>> who by? I can suggest a few improvements, the main one being to filter
>> the command output used to get prerequisites in a pipeline
>> (execute_command() with multiple commands using grep) and better error
>> checking. Also perhaps dumpbin should only be used if objdump is not
>> available.
>
Thanks for replying.
> It is not supported by anyone in particular.  However, it is a 
> supported and well used part of CMake.  I would suggest that you 
> create a patch, and work on the cmake-developers mailing list:
> http://www.cmake.org/gitweb?p=cmake.git;a=blob_plain;f=CONTRIBUTING.rst;hb=master 
>
OK, I will see what I can come up with.
>
> Looking at the code, it seems that objdump is intended for MinGW. I 
> wonder if there is a less verbose mode that can get the same 
> information.  OR, it seems that MinGW has ldd (at least mine does). 
> What happens if you use the ldd mode?
It uses dumpbin.exe in preference to objdump if it can find it and it 
even has hard coded paths to find it even if it is not on the PATH. Back 
at MinGW 4.8 dumpbin works OK but somewhere between there and MinGW 
4.9.2 the compiler support DLLs have changed and cause dumpbin to barf.

I have checked for objdump command options to reduce the output but 
there don't appear to be any that help. TBH running from the command 
line as, for example:

  $ objdump -p <executable> | grep 'DLL Name:'

runs in a fraction of a second compared with up to 10 minutes on an i7 
CPU for the GetPrerequisites version that messes around with the output 
in a CMake variable.

AFAIK ldd is an ELF format tool and there is no COFF equivalent for 
native Windows PE binaries.
>
> I would suggest that you try some stuff and see what actually works 
> with your system and then report back to the cmake-developers list 
> with either a complete patch or an approach that works and I can help 
> you get it into CMake.  Thanks for the contribution.
I thought that was what I had done. OK I will see if I can brew up a 
patch but it will be a big change as I see several more issues in 
GetPrerequisites and I am not a CMake expert.
>
> -Bill
>
Regards
Bill Somerville.


More information about the CMake mailing list