dyld not loading Ogre library - c++

I am trying to setup an environment to develop an Ogre3D application. I have manually compiled Ogre into folder /opt/Ogre3D/ogre-1.11.5/build and created a CMake project in CLion with this content:
cmake_minimum_required(VERSION 3.13)
project(sample)
set(CMAKE_CXX_STANDARD 14)
set(OGRE_DIR /opt/Ogre3D/ogre-1.11.5/build/sdk/cmake)
# specify which version and components you need
find_package(OGRE 1.11 REQUIRED COMPONENTS Bites RTShaderSystem)
# copy resource.cfg next to our binaries where OGRE looks for it
file(COPY ${OGRE_CONFIG_DIR}/resources.cfg DESTINATION ${CMAKE_BINARY_DIR})
add_executable(sample main.cpp)
target_link_libraries(sample ${OGRE_LIBRARIES})
when I try to run it, compilation is OK but then it can't execute it:
/Users/diego/CLionProjects/ogre/sample/cmake-build-debug/sample
dyld: Library not loaded: #executable_path/../Frameworks/OgreBites.framework/Versions/1.11.5/OgreBites
Referenced from: /Users/diego/CLionProjects/ogre/sample/cmake-build-debug/sample
Reason: image not found
Process finished with exit code 6
I have looked at otool -l /opt/Ogre3D/ogre-1.11.5/build/lib/macosx/OgreBites.framework/Versions/1.11.5/OgreBites and there is a command LC_ID_DYLIB with the name #executable_path/../Frameworks/OgreBites.framework/Versions/1.11.5/OgreBites, which matches the path given in the runtime error. However I don't know which step to take now as I have few experience with native library resolution on macOS.
Update:
Executing the command install_name_tool makes the linker find the library, but then it fails with the next one. I suppose/hope there is an option in CMake to pass it to the compiler so the binary files created during Ogre's compilation do not use the #execute_path directive?

I'm faced with the same problem, when using clion to build ogre in macos.
I found the symbolic links were invalid in the directory cmake-build-debug/bin/SampleBrowser.app/Contents/Frameworks.
I guess these symbolic links should point to
these frameworks int the cmake-build-debug/lib/macosx. So I modified the file where executed ln to create these symbolic links.
In the file Samples/Browser/CMakeLists.txt, change
set(OGRE_OSX_BUILD_CONFIGURATION "${CMAKE_OSX_SYSROOT}/$(CONFIGURATION)")
into
set(OGRE_OSX_BUILD_CONFIGURATION "macosx")
And clean and rebuild, then the problem will disappear.

Related

Undefined reference errors when trying to compile and simple ImageMagick program

I've been searching for a solution to this problem for a long time to no avail.
I am trying to compile this simple program:
#include <iostream>
#include <Magick++.h>
#include <Magick++/Image.h>
using namespace std;
using namespace Magick;
int main(int argc,char **argv) {
InitializeMagick("D:\\Programming\\CPPProjects\\NoteScripts\\Dependencies\\magick\\include");
Image image;
// image.read("arch");
// image.write("test.png");
}
Upon building, I get the following error:
CMakeFiles\main.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x1c): undefined reference to `Magick::InitializeMagick(char const*)'
CMakeFiles\main.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x28): undefined reference to `Magick::Image::Image()'
CMakeFiles\main.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x34): undefined reference to `Magick::Image::~Image()'
collect2.exe: error: ld returned 1 exit status
From what I can tell, this is a linker error but I have no idea where I am going wrong with linking the libs needed.
I installed ImageMagick on Windows 10 from the ImageMagick downloads page with this installer: ImageMagick-7.1.0-50-Q16-HDRI-x64-dll.exe
I then copied the lib files from the lib folder under the installation directory into my project and then copied the include folder under the installtion directory into my project.
Here is what the project hierarchy looks like (Source Directory is NoteScripts):
My CMakeLists.txt consists of:
cmake_minimum_required(VERSION 3.10)
set( CMAKE_CXX_COMPILER "C:/Program Files/mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/bin/g++.exe")
set( CMAKE_C_COMPILER "C:/Program Files/mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/bin/gcc.exe" )
# set the project name
project("Notes")
include_directories(D:/Programming/CPPProjects/NoteScripts/Dependencies/magick/include)
# add the executable
add_executable(main main.cpp)
target_link_libraries(main D:/Programming/CPPProjects/NoteScripts/Dependencies/magick/lib/CORE_RL_Magick++_.lib)
target_link_libraries(main D:/Programming/CPPProjects/NoteScripts/Dependencies/magick/lib/CORE_RL_MagickCore_.lib)
target_link_libraries(main D:/Programming/CPPProjects/NoteScripts/Dependencies/magick/lib/CORE_RL_MagickWand_.lib)
If I comment out lines 9 and 10 where InitializeMagick() is called and where Image image is declared, the program compiles without error. I'm also aware that the order of the static libs listed out matters but trying out multiple combinations has resulted in the same error. I have also verfied the dependency order by sifting through the original source code and the reference path is Magick++ -> MagickCore -> MagickWand.
I am relatively new to the process of adding external dependencies to my C++ projects so this is unfamiliar territory (coming from languages with clean package managers). Any help as to how to fix this issue is greatly appreciated!
The typical (and easiest) way of handling dependencies in CMake is using its find_package command:
find_package(ImageMagick REQUIRED COMPONENTS MagickCore MagickWand Magick++)
// ...
target_link_libraries(main ${ImageMagick_LIBRARIES})
This method is available for ImageMagick with your CMake version. I'm not familiar with CMake on Windows, but find_package by default searches a number of standard (system) locations for the package's files. Since you have a custom setup, it should also be possible to specify a nonstandard search prefix to the command. Additionally, you could download external dependencies in a portable way with the FetchContent commands.
First of all, it is a pain to setup this thing if you are a newbie like me.
Now to the steps to dynamically link imagemagick libs with your C app:
go to https://github.com/ImageMagick/ImageMagick-Windows and follow the instructions there (Install Visual Studio dependencies - Clone the dependencies - Build configure.exe- Build ImageMagick)
in the step Build configure.exe, when running configure.exe, keep the default option selected when asked about the output library type (keep it set to dynamic)
in the Build ImageMagick step, when you open VisualDynamicMT.sln in visual studio, before you start the build, select all the solutions in the project, and right-click -> properties -> General -> C Language Standard -> choose Default (Legacy MSVC). After that, click on the top-most solution that contains all the other 196 solutions, and build it. watch the console for errors, I didn't get any errors with the configuration above.
After the latter step, go the VisualMagick folder (created from steps before), and you will see lib folder and bin folder. You're done, your dlls are in bin and your .lib file are in bin folder. Note that these files will be corresponding to build or release environments depending on what you selected in visual studio at the build step.
How do you use imagemagick now in your project regardless if you have imagemagick app installed on your pc or not? Lets create a new project in vscode, call it demo.
Create this project structure:
inside src you will put your C code.
inside deps create ImageMagick/lib and ImageMagick/bin and ImageMagick/include
inside ImageMagick/include place the same include files you said you got in your question.
inside ImageMagick/lib place the .lib files you got from above
inside ImageMagick/bin place the .dll files you got from above
now add this to your CMakeLists.txt:
cmake_minimum_required(VERSION 3.23)
project(demo-app C)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
file(GLOB SOURCE_FILES src/*.c)
add_executable(demo ${SOURCE_FILES})
include_directories(src)
# ImageMagick
if(WIN32)
add_definitions( -DMAGICKCORE_QUANTUM_DEPTH=16 )
add_definitions( -DMAGICKCORE_HDRI_ENABLE=0 )
include_directories(deps/ImageMagick/include)
target_link_directories(demo PRIVATE deps/ImageMagick/lib)
file(GLOB IMAGEMAGICK_LIBS deps/ImageMagick/lib/*.lib)
target_link_libraries(demo
"${IMAGEMAGICK_LIBS}"
)
add_custom_command(TARGET demo POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory
"${PROJECT_SOURCE_DIR}/deps/ImageMagick/bin"
$<TARGET_FILE_DIR:demo>)
endif()
(The add_custom_command will copy the dlls to your executables path after every build)
Now write some magick code in you src directory.
ctrl + shift + A -> CMake select kit -> choose the Visual Studio community 2022 release -amd64 or change to what fits you if it doesn't work
ctrl + shift + A -> CMake Clean Rebuild
ctrl + shift + A -> CMake run without debugging

cmake + cpp: No such file or directory

I've I'm trying to build this "Hello World" wxWidgets example on Linux, using the following cmake script:
cmake_minimum_required (VERSION 2.6)
project (wxL)
find_package(wxWidgets 3.0.0 REQUIRED
COMPONENTS base core net xml html adv qa richtext
)
file(GLOB SOURCES "src/*.cpp")
add_executable(wxL ${SOURCES})
Building the project yields this error:
src/wxL.cpp:3:10: fatal error: wx/wxprec.h: No such file or directory
The file specified in the include, wx/wxprec.h can be found on disk at this location:
/usr/include/wx-3.0/wx/wxprec.h
Furthermore, another program that I have built from source includes the same file (also using cmake) and builds just fine.
So, how do I use cmake to tell the compiler that the file should be included from somewhere in the system directories?
I know I'm missing something basic, but I can't figure out what.
Although you've found the package, your executable does not know anything about it.
For the executable to compile correctly, it needs to find header files for your package together with the .so / .a files. Following example should get you started:
include_directories(${wxWidgets_INCLUDE_DIRS})
add_executable(wxL <add-source-files-here>)
target_link_libraries(wxL ${wxWidgets_LIBRARIES}) // links wxWidgets libraries to your executable
Please note that using glob is not a recommended way of adding source files to your project.

CMake not building a library when added as a subdirectory

I added the xgboost library as a git submodule of my project and I'm trying to add it to cmake as a subdirectory. Unfortunately it's not working. A simple hello world project with the following CMakeLists.txt replicates the error that I'm getting.
cmake_minimum_required(VERSION 3.2)
project(foo)
add_subdirectory(xgboost)
add_executable(${PROJECT_NAME} foo.cpp)
target_link_libraries(${PROJECT_NAME} xgboost)
After building the library there is nothing in the xgboost/lib directory so I get the following error.
clang: error: no such file or directory:
'/Users/.../myproject/xgboost/lib/libxgboost.dylib'
I think that the problem is generated in their CMakeLists file since they have two different targets. Maybe cmake is choosing the wrong target but I'm not familiar enough with cmake to figure it out. The following code is from xgboost's CMakeLists.
# Executable
add_executable(runxgboost $<TARGET_OBJECTS:objxgboost> src/cli_main.cc)
set_target_properties(runxgboost PROPERTIES
OUTPUT_NAME xgboost
)
set_output_directory(runxgboost ${PROJECT_SOURCE_DIR})
target_link_libraries(runxgboost ${LINK_LIBRARIES})
# Shared library
add_library(xgboost SHARED $<TARGET_OBJECTS:objxgboost>)
target_link_libraries(xgboost ${LINK_LIBRARIES})
set_output_directory(xgboost ${PROJECT_SOURCE_DIR}/lib)
#Ensure these two targets do not build simultaneously, as they produce outputs with conflicting names
add_dependencies(xgboost runxgboost)
My questions in order of importance are:
Is there any way to fix it without modifying xgboost's CMakeLists.txt file?
Is it reasonable to try to add xgboost to my project as a git submodule?
Is there any reason cmake is not instructing to build the library?
Note: There were several edits to this question since I tried to narrow down the problem and to provide more information.
(I would love to ask for few things beforehand in the comment section, but I have too low reputation to do so, so I will just give it a shot ;))
I have few suspects, and one of them is ${CMAKE_SOURCE_DIR} of the submodule's root CMakeLists.txt. Although the paths are set properly when you run that CMakeLists.txt alone, cmake gets confused the moment you add it as your subdirectory. Have you looked into another directories for your output binaries?
First I would suggest testing this hypothesis, and then I would suggest writing similar, but separate CMakeLists.txt file for xgboost library, and then substitute it in the project temporarily. Unfortunately the CMakeLists.txt filename is hardcoded and there is no possibility to have two files of that kind in one directory; so it seems that the answer to 1) is, that you rather have to change the file.
For the 2): as long as it does not require huge additional logic in your CMakeLists.txt, it makes sense. Other viable option is to create an install target, which you can use to install your xgboost library locally (using CMAKE_INSTALL_PREFIX(doc) variable), and then add the installation path to your CMAKE_LIBRARY_PATH(doc).

Trying to link a SFML-app on fedora 25

Hi everyone,
I have some trouble trying to use the SFML library.I've tried different thing to make it work but always failing.
I downloaded the official package but nothing worked when I tried to compile a basic program.
I downloaded the version 2.4.1and put includes folder in /src/local/include/ and libs files in /src/local/lib/. It was better than with the official package : I successfully got my .o. But the linking phase told me to install the jpeg library. So I did it but it was already installed on my system (Fedora 25) and doesn't changed anything. I saw on some forums that fedora use an other library to create jpeg picture : libjpeg-turbo which is a fork of the libjpeg. I have tried many thing to force my linux to use the libjpeg 8 instead of the one installed but without success.
To make it work I tried the last solution : compile the SFML myself. So I downloaded sources, launch cmake and saw that it was missing lot something like 8 libraries to my laptop. After installed all those libraries I compile and install the SFML with the make target. Once it was done the compiling phase still working but the linking phase return me a obscure message for me (I translated it) :
/usr/bin/ld: test: hidden symbol « __cpu_model » in
/usr/lib/gcc/x86_64-redhat-linux/6.2.1/libgcc.a(cpuinfo.o) is
referenced by DSO
/usr/bin/ld : Failure during final link editing : Wrong value
collect2: error : ld has returned 1 execution status code
Do anyone know what's wrong ?
SFML has issues with gcc 5.3 and newer. Currently GCC is version 6.3.1 in Fedora 25 repositories. You should apply this patch:
diff --git a/src/SFML/Graphics/CMakeLists.txt b/src/SFML/Graphics/CMakeLists.txt
index 6f02fb6..bdc84e7 100644
--- a/src/SFML/Graphics/CMakeLists.txt
+++ b/src/SFML/Graphics/CMakeLists.txt
## -148,6 +148,13 ## add_definitions(-DSTBI_FAILURE_USERMSG)
# when gcc is used; otherwise saving PNGs may crash in stb_image_write
if(SFML_COMPILER_GCC)
set_source_files_properties(${SRCROOT}/ImageLoader.cpp PROPERTIES COMPILE_FLAGS -fno-strict-aliasing)
+
+endif()
+
+# see https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
+if(SFML_COMPILER_GCC AND BUILD_SHARED_LIBS)
+ message(WARNING "Applying workaround for https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899")
+ list(APPEND GRAPHICS_EXT_LIBS "-lgcc_s -lgcc")
endif()
# define the sfml-graphics target
If you do not want to download the SFML git repository, just open src/SFML/Graphics/CMakeLists.txt, locate the if conditional statement with the ImageLoader.cpp comment (line 150) and append the lines added by the patch. The end result should look like this:
# ImageLoader.cpp must be compiled with the -fno-strict-aliasing
# when gcc is used; otherwise saving PNGs may crash in stb_image_write
if(SFML_COMPILER_GCC)
set_source_files_properties(${SRCROOT}/ImageLoader.cpp PROPERTIES COMPILE_FLAGS -fno-strict-aliasing)
endif()
# see https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899
if(SFML_COMPILER_GCC AND BUILD_SHARED_LIBS)
message(WARNING "Applying workaround for https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899")
list(APPEND GRAPHICS_EXT_LIBS "-lgcc_s -lgcc")
endif()

CMake+Xcode: Archive fails for an app depending on a library in the same solution. Make Archive build in the BUILD_TREE instead of Xcode/DerivedData?

We ported our codebase to use CMake for build management some weeks ago. We realize now that there is a major problem when we are trying to Archive an application that depends on one (or several) library built in the same Xcode solution.
The linker fails because it cannot find the depended upon library (and the library is indeed not present where it is looking for it).
minimal example 
Here is a minimal example producing the issue:
In CMakeLists.txt
##
## The library
##
project(library)
add_library(${PROJECT_NAME}
utils.h
utils.cpp
)
##
## The application
##
project(CocoaApp)
set(${PROJECT_NAME}_XIB
MainMenu.xib
)
add_executable(${PROJECT_NAME} MACOSX_BUNDLE
AppDelegate.h
AppDelegate.mm
${${PROJECT_NAME}_XIB}
main.mm
)
target_link_libraries(${PROJECT_NAME} library "-framework Cocoa")
set_target_properties(${PROJECT_NAME} PROPERTIES
RESOURCE "${${PROJECT_NAME}_XIB}")
When generating an Xcode project from this simple CMake scripts, if trying to call Archive command, the compilation phase itself goes fine, but the linker phase fails with this error:
clang: error: no such file or directory: '<path_to_build_tree>/Release/libLibrary.a'
And there is indeed no libLibrary.a to be found in ${build_tree}/Release/. (If the library target was first compiled in Release, the file would already be there, but it is not viable as Archive should be self contained.)
Is this a bug ? Is there a workaround ?
Edit: setting ARCHIVE_OUTPUT_DIRECTORY on the lib
If ARCHIVE_OUTPUT_DIRECTORY is set for the Library target, then a file is indeed created in CMake's build_tree. Actually setting its value to "./" even places it where a 'normal' Release build would place the library.
The problem here is that the file that is placed in the build_tree is merely a soft link to the actual library (in ~/Library/Developer/Xcode/DerivedData/.../.../libLibrary.a). Instead, we would need that the "Archive" action builds the actual file here, exactly like a Release build would (or at least move it there when its done).