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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake