[CMake] Add CXX dependency generation to custom command for Ninja?
Hi,
We have a custom command for a third-party utility (genreflex, from the
ROOT system) which has a directive:
IMPLICIT_DEPENDS CXX ${CMAKE_CURRENT_SOURCE_DIR}/classes.h
How would I, either as an extra COMMAND or as a separate custom command,
manually invoke the configured CXX compiler with all the
correctly-configured include directories and other pre-processor and
compiler flags with the expected option (-MMD for GCC, I think) on the
above-mentioned classes.h file so that the resulting file can be used in
a DEPFILE directive for the Ninja generator? I would like to model as
closely as possible exactly what CMake would specify to invoke the
compiler to (e.g.) compile an object with only the necessary changes,
but I'm not sure whence to obtain this information. I'm assuming it's
some combination of automatic variables and properties via generator
expressions, but I'm at a loss, I'm afraid. I also don't know whether I
would need to specify the .d file as an OUTPUT or a BYPRODUCTS if I do
this as a COMMAND, or in DEPENDS in addition to DEPFILE if a separate
custom command, and which choice would be better (assuming both of them
work). The resulting CMake code would need to conditionally support both
Makefile and Ninja generators.
Any advice gratefully accepted.
Current custom command definition:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${dictname}_dict.cpp
${SOURCE_OUTPUT} ${GD_ROOTMAP_OUTPUT} ${PCM_OUTPUT}
COMMAND ${ROOT_GENREFLEX} ${CMAKE_CURRENT_SOURCE_DIR}/classes.h
-s ${CMAKE_CURRENT_SOURCE_DIR}/classes_def.xml
-I${CMAKE_SOURCE_DIR}
${GENREFLEX_INCLUDES} ${GENREFLEX_FLAGS}
-o ${dictname}_dict.cpp
${CLEANUP_COMMAND}
IMPLICIT_DEPENDS CXX ${CMAKE_CURRENT_SOURCE_DIR}/classes.h
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/classes_def.xml
COMMENT "Generating dictionary files for target ${dictname}"
)
Many thanks,
Chris.
--
Chris Green , FNAL CS/SCD/ADSS/SSI/TAC;
'phone (630) 840-2167; Skype: chris.h.green;
IM: gre...@jabber.fnal.gov, chissgreen (AIM),
chris.h.green (Google Talk).
--
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
Re: [CMake] Platform-independent config package
You can temporarily unset CMAKE_SIZEOF_VOID_P before calling write_basic_package_version_file. See for instance https://bitbucket.org/eigen/eigen/src/ff6170e75ab07d74d8f7dd21af777a94799d168d/CMakeLists.txt?at=3.3&fileviewer=file-view-default#CMakeLists.txt-541:545 . On Tue, Jan 10, 2017 at 7:52 PM, Ghislain Vaillant wrote: > Dear all, > > I am currently hit by an issue with the CMake detection of a header-only > library [1]. The library is built on a 64-bit machine and packaged for all > other architectures supported by Debian. > > However, CMake detection fails on 32-bit platforms with the following > error: > > ``` > Any attempt to call `find_package(glm REQUIRED)` produces the following > error: > > ``` > Could not find a configuration file for package "glm" that is > compatible with requested version "". > > The following configuration files were considered but not accepted: > > /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit) > ``` > > How can this be effectively solved? Can the bit-ness detection be dropped > somehow? It should not be needed for a header-only target. > > Cheers, > Ghis > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277 > > -- > > 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 > -- 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
[CMake] Custom command on cpack target
I would like to run a custom command on the zip file generated by cpack. The idea is that I want to calculate its sha256 checksum. Unfortunately it seems the zip file cannot be a target in a CMakeLists.txt file or I'm doing something wrong. Can someone give me a hand? -- Gonzalo Garramuño -- 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
Re: [CMake] Platform-independent config package
Dear Ghis, the easiest long-term fix would be an own glmConfig.cmake file. The command write_basic_package_version_file uses a template with those pointer checks. The glm-developers could simply copy the template to their source directory, remove the unneeded lines and run the configure_file command themself on the changed template. The short solution for debian would be a patch file,which just uncomments the last 5 lines. Regards, Andreas Am 10.01.2017 um 19:52 schrieb Ghislain Vaillant: Dear all, I am currently hit by an issue with the CMake detection of a header-only library [1]. The library is built on a 64-bit machine and packaged for all other architectures supported by Debian. However, CMake detection fails on 32-bit platforms with the following error: ``` Any attempt to call `find_package(glm REQUIRED)` produces the following error: ``` Could not find a configuration file for package "glm" that is compatible with requested version "". The following configuration files were considered but not accepted: /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit) ``` How can this be effectively solved? Can the bit-ness detection be dropped somehow? It should not be needed for a header-only target. Cheers, Ghis [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277 -- 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
[CMake] Chocolatey? (Windows)
I was wondering if anyone was familiar with Chocolatey and whether there are plans to add support for it in cmake/cpack. For those that don't know, Chocolatey is a small Windows' utility similar to Debian's apt-get. It allows simple management of packages (binaries mainly). -- 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
[CMake] Platform-independent config package
Dear all, I am currently hit by an issue with the CMake detection of a header-only library [1]. The library is built on a 64-bit machine and packaged for all other architectures supported by Debian. However, CMake detection fails on 32-bit platforms with the following error: ``` Any attempt to call `find_package(glm REQUIRED)` produces the following error: ``` Could not find a configuration file for package "glm" that is compatible with requested version "". The following configuration files were considered but not accepted: /usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit) ``` How can this be effectively solved? Can the bit-ness detection be dropped somehow? It should not be needed for a header-only target. Cheers, Ghis [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850277 -- 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
[CMake] Problems building a MODULE library (OpenFX plugin) with correct cuda object linking
Hello,
after hours and hours of searching and trying to get it to work I hope
someone here can help me as I'm now out of ideas. I'm trying to build an
OpenFX plugin for DaVinci Resolve (a movie color grading software,
https://www.blackmagicdesign.com/products) via CMake. Resolve is
delivered with a developer sample plugin using a standard Makefile (Mac)
and project files for Apple XCode/VisualStudio. But for a better
structure I wanted to build a CMake build framework for this plugin.
Notes for better understanding: The CUDA implementation is a proprietary
Add On to the OpenSource OpenFX interfaces as far as I understand it.
Stock OpenFX would pass memory references only to host memory address
space while the Resolve extension passed CUDA/OpenCL addresses to reduce
memory transfer overhead for better real time processing. OpenFX plugins
are build as bundles of objects(?) (MODULE library build in CMake).
The basic structure is a plugin that offers processing with CPU, OpenCL
or CUDA depending on the processing mode the host application is using.
This plugin is bundled into a single module library which is loaded by
Resolve. For the plugin a few helper classes are used to handle the
Plugin metadata (user interface, host communication) while CUDA/OpenCL
control code is also seperated into two separate files (OpenCLKernel.cpp
and CudaKernel.cu). Both contain the GPU Kernel itselt and a host
function which is included in the main Plugin just via extern
declaration. Sample:
extern void RunCudaKernel(int p_Width, int p_Height, float* p_Gain,
const float* p_Input, float* p_Output);
The Makefile then just compiles all cpp files with the standard $(CXX)
compiler and the CudaKernel.cu with $(NVCC) which is defined before.
Then a simple
$(CXX) -bundle $^ -o $@ -L${CUDAPATH}/lib -lcuda -lcudart
-F/Library/Frameworks -framework CUDA -framework OpenCL
does the linking and works fine.
I tried to replicate this structure of linking in CMake and it works as
long as I keep CUDA deactivated (One of the reasons of building a
flexible CMake infrastructure is making a few parts configurable via
CMake/Compiler options). Most stuff is working now, but I have a problem
integrating the CUDA part.
For OpenCL I just build an object library from the OpenCLKernel.cpp and
add it as a target object:
add_library(GainLibOpenCL OBJECT OpenCLKernel.cpp)
...
add_library(${PLUGIN_NAME} MODULE src/${PLUGIN_NAME}.cpp
$)
I tried to replicate this for the CUDA code but cuda_add_library doesn't
seem to support generating object files and a combination of
cuda_compile + add_library also doesn't allow to generate object files
so how do I replicate the Makefile result.
Here are two examples how I tried different methods. Did a few more
tests based on many results of questions on the net but non solved my
problem.
Variant 1:
cuda_add_library(GainLibCUDA CudaKernel.cu)
set(LIBS ${LIBS} GainLibCUDA PARENT_SCOPE)
Will compile but result in a crash of Resolve, with STATIC as an option
for cuda_add_library it builds and Resolve stays open, but processing
isn't working. And it links to the CUDA static libraries which isn't
intended as the host cuda lib should be used.
cuda_compile(cuda_exec_obj CudaKernel.cu)
add_library(GainLibCUDA OBJECT CudaKernel.h ${cuda_exec_obj})
set(TARGET_OBJECTS ${TARGET_OBJECTS} $
PARENT_SCOPE)
Results in the error:
CMake Error at src/CUDA/CMakeLists.txt:21 (add_library):
OBJECT library "GainLibCUDA" contains:
cuda_compile_1_generated_CudaKernel.cu.o
but may contain only sources that compile, header files, and other
files
that would not affect linking of a normal library.
Also just adding "cuda_compile(cuda_exec_obj CudaKernel.cu)" and then
${cuda_exec_obj} as a file to the "add_library(${PLUGIN_NAME} MODULE
..." line results in and error: "Cannot find source file".
So this mail got pretty long but I hope this helps someone to help me
and then also help others if they reach a similar problem.
Kind regards,
Ingmar
--
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
Re: [CMake] Find Vulkan on 32 bit builds
There's a couple of ways to fix this; for instance, on Windows I could use NO_DEFAULT_PATH on the find_library call and that would resolve the issue. The main reason why I haven't done this yet is because I think that's a packaging bug in the Vulkan SDK side which I was going to report there (I want to ask them to move the libraries into a lib/ subfolder, and ideally use different names for different architectures.) Ideally they would just provide CMake config files then… Eike -- -- 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
Re: [CMake] Find Vulkan on 32 bit builds
That makes sense! Removing the variable from PATH does indeed fix the issue.
It is not a blocking issue for me.
I agree that this is a Vulkan packaging issue. However, since you are
looking for $ENV{VULKAN_SDK} in the find module and assuming it exists,
then it 'should' override the other path? I do see what you are saying in
that this now becomes a special case just because Vulkan SDK didn't package
the libs properly.
Thanks Matthäus and Andreas for your help!
On Tue, Jan 10, 2017 at 10:38 AM Matthäus G. Chajdas
wrote:
Hi,
the problem here is that the Vulkan SDK helpfully adds
D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
PATH, and because the libraries for both architectures are named the
same, it will pick up the one from /Bin first (as the search order for
find_library is system paths first, and PATHS/HINTS variable second).
There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different architectures.)
For now the easiest workaround is to remove the path to the Vulkan SDK
from PATH; and I'll try to report this with the LunarG SDK and see how
far I get there. If this doesn't work out, I'll guess I'll have to
special-case the find_library call to ignore default paths on Windows &
32-bit only.
If this is a blocker for you, please file an issue and I'll fix it on
the CMake end before even starting the discussion with LunarG.
Cheers,
Matthäus
Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
> Hello,
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>> Hello,
>>
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>> variables both point to the "Bin" folder for the Vulkan installation
>> instead of the "Bin32" folder.
>>
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>> mistake setting up. The message does indeed print confirming that my
>> pointer size is 4 and thus the current toolchain selected is 32 bit.
>>
>> What's perplexing is that when I do a MESSAGE(STATUS
>> ${Vulkan_LIBRARY}) the path is:
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib
>>
>>
>> instead of
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>>
>>
>>
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
>> ignoring 32?
>>
> You should think the other way around: Why should cmake look in a
> special directory, when it finds a library with an appropriate name
> before this one?
> This decision should be in the corresponding FindVulkan.cmake, i.e. the
> corresponding find_library call should be constrained to
> ${VULKAN_DIR}/Bin32 in the 32bit case.
>>
>>
>
> Regards,
> Andreas
--
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
Re: [CMake] Find Vulkan on 32 bit builds
Hi,
the problem here is that the Vulkan SDK helpfully adds
D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
PATH, and because the libraries for both architectures are named the
same, it will pick up the one from /Bin first (as the search order for
find_library is system paths first, and PATHS/HINTS variable second).
There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different architectures.)
For now the easiest workaround is to remove the path to the Vulkan SDK
from PATH; and I'll try to report this with the LunarG SDK and see how
far I get there. If this doesn't work out, I'll guess I'll have to
special-case the find_library call to ignore default paths on Windows &
32-bit only.
If this is a blocker for you, please file an issue and I'll fix it on
the CMake end before even starting the discussion with LunarG.
Cheers,
Matthäus
Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
> Hello,
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>> Hello,
>>
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>> variables both point to the "Bin" folder for the Vulkan installation
>> instead of the "Bin32" folder.
>>
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>> mistake setting up. The message does indeed print confirming that my
>> pointer size is 4 and thus the current toolchain selected is 32 bit.
>>
>> What's perplexing is that when I do a MESSAGE(STATUS
>> ${Vulkan_LIBRARY}) the path is:
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib
>>
>>
>> instead of
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>>
>>
>>
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
>> ignoring 32?
>>
> You should think the other way around: Why should cmake look in a
> special directory, when it finds a library with an appropriate name
> before this one?
> This decision should be in the corresponding FindVulkan.cmake, i.e. the
> corresponding find_library call should be constrained to
> ${VULKAN_DIR}/Bin32 in the 32bit case.
>>
>>
>
> Regards,
> Andreas
--
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
[CMake] Bundling for OS X
(Full source is available at https://github.com/rjhansen/sherpa )
I have a Qt 5.7 application which I'm trying to migrate from qmake to
cmake 3.7. So far it almost works on OS X, except when it comes to
making a proper app bundle.
The relevant contents of my CMakeLists.txt are as follows:
=
install(DIRECTORY "${QT_PLUGINS_DIR}/imageformats" DESTINATION
${plugin_dest_dir}/plugins COMPONENT Runtime)
install(CODE "
file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qtconf_dest_dir}/qt.conf\" \"\")
" COMPONENT Runtime)
set(DIRS ${QT_LIBRARY_DIRS})
install(CODE "
file(GLOB_RECURSE QTPLUGINS
\"\${CMAKE_INSTALL_PREFIX}/${plugin_dest_dir}/plugins/*${CMAKE_SHARED_LIBRARY_SUFFIX}\")
include(BundleUtilities)
fixup_bundle(\"${APPS}\" \"\${QTPLUGINS}\" \"${DIRS}\")
" COMPONENT Runtime)
# To Create a package, one can run "cpack -G DragNDrop
CPackConfig.cmake" on Mac OS X
# where CPackConfig.cmake is created by including CPack
# And then there's ways to customize this as well
set(CPACK_BINARY_DRAGNDROP ON)
include(CPack)
=
Some of this was taken from CMake's example Qt4/OS X application, but
Qt5 changed enough that the Qt4 example doesn't quite work. Although it
creates an app bundle, the linkage points all over the map:
=
quorra:Sherpa rjh$ otool -L Sherpa.app/Contents/MacOS/Sherpa
Sherpa.app/Contents/MacOS/Sherpa:
@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version
5.7.0, current version 5.7.0)
/usr/local/lib/libgpgme.11.dylib (compatibility version 29.0.0, current
version 29.0.0)
/usr/local/lib/libassuan.0.dylib (compatibility version 8.0.0, current
version 8.3.0)
/usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (compatibility
version 22.0.0, current version 22.0.0)
/usr/local/opt/minizip/lib/libminizip.1.dylib (compatibility version
2.0.0, current version 2.0.0)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.7.0,
current version 5.7.0)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.7.0,
current version 5.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
307.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1238.0.0)
=
Qt comes with a tool, macdeployqt, which seems to mangle the app bundle
beyond reason:
=
quorra:Sherpa rjh$ ~/Qt5.7.0/5.7/clang_64/bin/macdeployqt Sherpa.app
quorra:Sherpa rjh$ open Sherpa.app
LSOpenURLsWithRole() failed with error -10810 for the file
/Users/rjh/Projects/Sherpa/Sherpa.app.
=
Although macdeployqt *appears* to copy and relink things correctly,
invoking the binary directly yields the problem: "dyld: initializer
function 0x1082cfbd5 not in mapped image for
/usr/local/lib/libgpg-error.0.dylib" -- whatever that means.
tl;dr -- How can I copy my libraries (GPGME_LIBRARY, ASSUAN_LIBRARY,
GPGERR_LIBRARY, MINIZIP_LIBRARY, as well as QtWidgets, QtCore, and
QtGui) into the bundle and run install_name_tool to correctly relink the
application to the in-bundle libs?
--
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
