I'm trying to make a very basic Qt5 application using CMake on Windows.
I used the documentation of Qt5 to use CMake, and my main.cpp file just contains a main function.
My CMakeLists.txt is exactly:
cmake_minimum_required(VERSION 2.8.9)
project(testproject)
# Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Instruct CMake to run moc automatically when needed.
set(CMAKE_AUTOMOC ON)
# Find the QtWidgets library
find_package(Qt5Widgets)
# Tell CMake to create the helloworld executable
add_executable(helloworld hello.cpp)
# Use the Widgets module from Qt 5.
qt5_use_modules(helloworld Widgets)
When in MSysGit bash I enter
$ cmake -G"Visual Studio 11"
I get this output:
$ cmake -G"Visual Studio 11"
-- The C compiler identification is MSVC 17.0.60204.1
-- The CXX compiler identification is MSVC 17.0.60204.1
-- Check for working C compiler using: Visual Studio 11
-- Check for working C compiler using: Visual Studio 11 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11
-- Check for working CXX compiler using: Visual Studio 11 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Warning at CMakeLists.txt:11 (find_package):
By not providing "FindQt5Widgets.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"Qt5Widgets", but CMake did not find one.
Could not find a package configuration file provided by "Qt5Widgets" with
any of the following names:
Qt5WidgetsConfig.cmake
qt5widgets-config.cmake
Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set
"Qt5Widgets_DIR" to a directory containing one of the above files. If
"Qt5Widgets" provides a separate development package or SDK, be sure it has
been installed.
CMake Error at CMakeLists.txt:17 (qt5_use_modules):
Unknown CMake command "qt5_use_modules".
-- Configuring incomplete, errors occurred!
Do you have any ideas?
After the lines
cmake_minimum_required(VERSION 2.8.9)
project(testproject)
add
set (CMAKE_PREFIX_PATH "C:\\Qt\\Qt5.0.1\\5.0.1\\msvc2010\\")
This solves the problem.
You should set the CMAKE_PREFIX_PATH environment variable instead or use the cmake-gui to set the path to the Qt 5 packages.
You need just add Qt path to Windows %PATH% variable. As suggested in official documentation: http://doc.qt.io/qt-4.8/install-win.html#step-3-set-the-environment-variables
Here's a technique that takes advantage of cmake's ability to read the registry to coerce a registry value into locating the matching msvc's Qt5Config.cmake.
It attempts to use the highest available Qt5 version by doing a reverse sort on the various "5.x" folder names inside (e.g. C:\Qt\).
This could be placed inside a module as well, e.g. QtLocator.cmake.
SET(QT_MISSING True)
# msvc only; mingw will need different logic
IF(MSVC)
# look for user-registry pointing to qtcreator
GET_FILENAME_COMPONENT(QT_BIN [HKEY_CURRENT_USER\\Software\\Classes\\Applications\\QtProject.QtCreator.cpp\\shell\\Open\\Command] PATH)
# get root path so we can search for 5.3, 5.4, 5.5, etc
STRING(REPLACE "/Tools" ";" QT_BIN "${QT_BIN}")
LIST(GET QT_BIN 0 QT_BIN)
FILE(GLOB QT_VERSIONS "${QT_BIN}/5.*")
LIST(SORT QT_VERSIONS)
# assume the latest version will be last alphabetically
LIST(REVERSE QT_VERSIONS)
LIST(GET QT_VERSIONS 0 QT_VERSION)
# fix any double slashes which seem to be common
STRING(REPLACE "//" "/" QT_VERSION "${QT_VERSION}")
# do some math trickery to guess folder
# - qt uses (e.g.) "msvc2012"
# - cmake uses (e.g.) "1800"
# - see also https://cmake.org/cmake/help/v3.0/variable/MSVC_VERSION.html
MATH(EXPR QT_MSVC "2000 + (${MSVC_VERSION} - 600) / 100")
# check for 64-bit os
# may need to be removed for older compilers as it wasn't always offered
IF(CMAKE_SYSTEM_PROCESSOR MATCHES 64)
SET(QT_MSVC "${QT_MSVC}_64")
ENDIF()
SET(QT_PATH "${QT_VERSION}/msvc${QT_MSVC}")
SET(QT_MISSING False)
ENDIF()
# use Qt_DIR approach so you can find Qt after cmake has been invoked
IF(NOT QT_MISSING)
MESSAGE("-- Qt found: ${QT_PATH}")
SET(Qt5_DIR "${QT_PATH}/lib/cmake/Qt5/")
SET(Qt5Test_DIR "${QT_PATH}/lib/cmake/Qt5Test")
ENDIF()
And then..
# finally, use Qt5 + COMPONENTS technique, compatible with Qt_DIR
FIND_PACKAGE(Qt5 COMPONENTS Core Gui Widgets Xml REQUIRED)
The #tresf's solution perfectly covers the whole idea. It's only one thing to add: Microsoft's versioning seems to be turning into geometric progression. The series is too short yet to confirm, so as of 2019' the following formula may be used:
# do some math trickery to guess folder
# - qt uses (e.g.) "msvc2012"
# - cmake uses (e.g.) "1800"
# - see also https://cmake.org/cmake/help/v3.0/variable/MSVC_VERSION.html
# - see also https://dev.to/yumetodo/list-of-mscver-and-mscfullver-8nd
if ((MSVC_VERSION GREATER_EQUAL "1920") AND (IS_DIRECTORY "${QT_VERSION}/msvc2019"))
set(QT_MSVC "2019")
elseif ((MSVC_VERSION GREATER_EQUAL "1910") AND (IS_DIRECTORY "${QT_VERSION}/msvc2017"))
set(QT_MSVC "2017")
elseif (MSVC_VERSION GREATER_EQUAL "1900")
set(QT_MSVC "2015")
else ()
MATH(EXPR QT_MSVC "2000 + (${MSVC_VERSION} - 500) / 100")
endif ()
One way is to open the CMakeLists.txt in Qt Creator. Qt Creator supports CMake natively and it always knows where Qt is.
Related
I am trying to include ANTLR in my cmake project, I closely followed the tutorial:
# minimum required CMAKE version
CMAKE_MINIMUM_REQUIRED(VERSION 3.7 FATAL_ERROR)
project(ANTLR_TEST)
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
# compiler must be 17
set(CMAKE_CXX_STANDARD 17)
# required if linking to static library
add_definitions(-DANTLR4CPP_STATIC)
# using /MD flag for antlr4_runtime (for Visual C++ compilers only)
set(ANTLR4_WITH_STATIC_CRT OFF)
# Specify the version of the antlr4 library needed for this project.
# By default the latest version of antlr4 will be used. You can specify a
# specific, stable version by setting a repository tag value or a link
# to a zip file containing the libary source.
# set(ANTLR4_TAG 4.11.1)
# set(ANTLR4_ZIP_REPOSITORY https://github.com/antlr/antlr4/archive/refs/tags/4.11.1.zip)
# add external build for antlrcpp
include(ExternalAntlr4Cpp)
# add antrl4cpp artifacts to project environment
include_directories(${ANTLR4_INCLUDE_DIRS})
# set variable pointing to the antlr tool that supports C++
# this is not required if the jar file can be found under PATH environment
set(ANTLR_EXECUTABLE ${CMAKE_CURRENT_SOURCE_DIR}/antlr_jar/antlr-4.11.1-complete.jar)
# add macros to generate ANTLR Cpp code from grammar
find_package(ANTLR REQUIRED)
# Call macro to add lexer and grammar to your build dependencies.
antlr_target(SampleGrammarLexer TLexer.g4 LEXER
PACKAGE antlrcpptest)
antlr_target(SampleGrammarParser TParser.g4 PARSER
PACKAGE antlrcpptest
DEPENDS_ANTLR SampleGrammarLexer
COMPILE_FLAGS -lib ${ANTLR_SampleGrammarLexer_OUTPUT_DIR})
# include generated files in project environment
include_directories(${ANTLR_SampleGrammarLexer_OUTPUT_DIR})
include_directories(${ANTLR_SampleGrammarParser_OUTPUT_DIR})
# add generated grammar to demo binary target
add_executable(demo main.cpp
${ANTLR_SampleGrammarLexer_CXX_OUTPUTS}
${ANTLR_SampleGrammarParser_CXX_OUTPUTS})
target_link_libraries(demo antlr4_static)
While building works on WSL it does not with Visual Studio:
3>Finished building the project antlr4_runtime-build_static.vcxproj.
4>------ Build started: Project: demo, Configuration: Debug x64 ------
4>Building Sample Grammar Lexer with ANTLR 4.11.1
4>Building Custom Rule D:/Q/OribosScript/OribosLang/src/CMakeLists.txt
4>Building SampleGrammarParser with ANTLR 4.11.1
4>main.cpp
4>TLexer.cpp
4>TParser.cpp
4>Generating code...
4>LINK : fatal error LNK1104: File "antlr4_runtime\src\antlr4_runtime\runtime\Cpp\dist\Debug\antlr4-runtime-static.lib" cannot be opened.
4>The creation of the project "demo.vcxproj" is complete -- ERROR.
However, src\build\antlr4_runtime\src\antlr4_runtime\runtime\Cpp\dist\antlr4-runtime-static.lib exists, so VS is apparently looking for a Debug folder that does not exist.
What do I need to change in my CMakeLists.txt to make it work on Windows, too?
I my library I use boost's float128 wrapper therefore changing the compiler is not an option.
Following Intel's developer guide I added find_package(IntelDPCPP REQUIRED) to my CMakeLists.txt and ran cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icx -GNinja on the VS 2022 terminal. I get the following error message
Found package configuration file:
C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/IntelDPCPP/IntelDPCPPConfig.cmake
but it set IntelDPCPP_FOUND to FALSE so package "IntelDPCPP" is considered
to be NOT FOUND. Reason given by package:
Unsupported compiler family and compiler icx!!
Anyone with a similar issue that can help out?
EDIT: as suggested by #Botje here the output information relevant to this case
IntelDPCPPConfig.cmake(84): string(COMPARE EQUAL ${CMAKE_CXX_COMPILER} nocmplr )
IntelDPCPPConfig.cmake(85): if(nocmplr)
IntelDPCPPConfig.cmake(93): if(NOT x${CMAKE_CXX_COMPILER_ID} STREQUAL xClang AND NOT x${CMAKE_CXX_COMPILER_ID} STREQUAL xIntelLLVM )
IntelDPCPPConfig.cmake(95): set(IntelDPCPP_FOUND False )
This is a known issue, it will be fixed in the OneAPI 2023.1 release.
You can try reversing the order of find_package and project or removing find_package(IntelDPCPP REQUIRED) in CMakeLists.txt. Because CMake identifies and sets up all the compiler-related variables when the project() is called.
Also, you can set the compiler option for the DPC++ compiler in CMakeLists.txt using the below command.
set(CMAKE_CXX_COMPILER dpcpp)
I can't find wxWidget on window. The error is:
CMake Error at E:/Program Files/JetBrains/CLion 2020.2.1/bin/cmake/win/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES
wxWidgets_INCLUDE_DIRS)`
My Env:
win10
cmake 3.17
wxWidgets 3.1.4
I use cmake to build and install the wxWidgets
mkdir build
cd build
cmake .. -config Release
cmake --build .
cmake --install .
Which install wxWidgets in D:/Program Files(x86)/wxWidgets.
The I set the env variable wxWidgets_ROOT_DIR to D:\Program Files (x86), because that's a code snnipt in cmake's script FindWxWidgets.cmake.
find_path(wxWidgets_ROOT_DIR
NAMES include/wx/wx.h
PATHS
ENV wxWidgets_ROOT_DIR
ENV WXWIN
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno Setup: App Path]" # WX 2.6.x
C:/
D:/
ENV ProgramFiles
PATH_SUFFIXES
wxWidgets-3.1.0
wxWidgets-3.0.2
wxWidgets-3.0.1
wxWidgets-3.0.0
wxWidgets-2.9.5
wxWidgets-2.9.4
wxWidgets-2.9.3
wxWidgets-2.9.2
wxWidgets-2.9.1
wxWidgets-2.9.0
wxWidgets-2.8.9
wxWidgets-2.8.8
wxWidgets-2.8.7
wxWidgets-2.8.6
wxWidgets-2.8.5
wxWidgets-2.8.4
wxWidgets-2.8.3
wxWidgets-2.8.2
wxWidgets-2.8.1
wxWidgets-2.8.0
wxWidgets-2.7.4
wxWidgets-2.7.3
wxWidgets-2.7.2
wxWidgets-2.7.1
wxWidgets-2.7.0
wxWidgets-2.7.0-1
wxWidgets-2.6.4
wxWidgets-2.6.3
wxWidgets-2.6.2
wxWidgets-2.6.1
wxWidgets-2.5.4
wxWidgets-2.5.3
wxWidgets-2.5.2
wxWidgets-2.5.1
wxWidgets
DOC "wxWidgets base/installation directory"
)
I think I have config right the wxWidgets_ROOT_DIR. Because I message the varialbe message(wxWidgets_ROOT_DIR " " ${wxWidgets_ROOT_DIR}) and It show the right value:
D:/Program Files(x86)/wxWidgets
The I use find_libarray(wxWidgets Required) in my project to find wxWidgets, and it shows the above error.
My question is:
How to fix it.
Or what find_package(xxx) do on window?
Update:
I finally find it's clion issue that use his cmake not the stand cmake. I use the stand cmake with vscode. And they works fine.
I also had problems with wxWidgets installation on Windows and CLion, I' ve followed these steps:
Download MinGW(32) and set as the default compiler for CLion (I had problems with other compilers)
Download the windows installer of wxWidgets from the official site (https://github.com/wxWidgets/wxWidgets/releases/download/v3.1.4/wxMSW-3.1.4-Setup.exe)
The installer will download all the files of the library in "C:\wxWidgets-3.1.4" and will also create the environment variable WXWIN that will contain the path of the folder "C:\wxWidgets-3.1.4"
Compile the library following this tutorial for MinGW https://wiki.wxwidgets.org/Compiling_wxWidgets_with_MinGW (make a coffee, it will take a while)
The compiler will but object files in "C:\wxWidgets-3.1.4\lib\gcc_dll", in "C:\wxWidgets-3.1.4\build\msw\gcc_mswudll" and probably in other places based on the instruction files in the "C:\wxWidgets-3.1.3\build" folder
After the compilation you need to add "C:/wxWidgets-3.1.4/lib/gcc_dll" in the environment variable PATH of the OS
After a restart write this code in the CMakeLists of your project:
cmake_minimum_required(VERSION 3.17)
project(your project name)
set(CMAKE_CXX_STANDARD 20)
SET(wxWidgets_USE_LIBS)
#for using RichTextCtrl
FIND_PACKAGE(wxWidgets REQUIRED richtext aui adv html core xml net base)
IF(wxWidgets_FOUND)
INCLUDE("${wxWidgets_USE_FILE}")
add_executable(your list of executables)
TARGET_LINK_LIBRARIES(note ${wxWidgets_LIBRARIES})
ELSE(wxWidgets_FOUND)
#for convenience. When we cannot continue,inform the user
MESSAGE("wxWidgets not found!")
ENDIF(wxWidgets_FOUND)
And now wxWidgets should work
I was able to build the samples using CLion and CMake on Mac OS, but much of what I learned should be similar, given CLion's cross-platform nature. The directions are very long, so here is a link:
https://forums.wxwidgets.org/viewtopic.php?p=197038#p187276
This question already has answers here:
Check CMake Cache Variable in Toolchain File
(2 answers)
Closed 1 year ago.
I'm writing CMake toolchain files for cross-compilation.
I've got several toolchains, that differ very slightly. I'd like to create a single file for cmake that describes all toolchains and have users to specify them from command line: cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake -DTOOLCHAIN_NAME=<name>
However, it seems that TOOLCHAIN_NAME sometimes becomes an empty string.
Here is the example of the toolchain file:
set(tools /opt/toolchains/Custom/toolchains/toolchain)
set(sdk /opt/toolchains/Custom/platforms/)
message(STATUS "toolchain_name ${TOOLCHAIN_NAME}")
if(NOT TOOLCHAIN_NAME)
message(SEND_ERROR "Please specify toolchain name in -DTOOLCHAIN_NAME parameter")
endif()
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR ARM)
# further processing
Then I call CMake:
mkdir build
cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchain.cmake -DTOOLCHAIN_NAME=proc-os-gnueabi-gcc_6_3
And get following output with errors:
-- toolchain name proc-os-gnueabi-gcc_6_3
-- toolchain name proc-os-gnueabi-gcc_6_3
-- The C compiler identification is GNU 6.3.1
-- The CXX compiler identification is GNU 6.3.1
-- Check for working C compiler: /opt/toolchains/.../bin/arm-os-gnueabi-gcc
CMake Error at /home/user/project/cmake/toolchain.cmake:59 (message):
Please specify toolchain name in -DTOOLCHAIN_NAME parameter
Call Stack (most recent call first):
/home/user/project/build/CMakeFiles/3.15.4/CMakeSystem.cmake:6 (include)
/home/user/project/build/CMakeFiles/CMakeTmp/CMakeLists.txt:2 (project)
CMake Error at /usr/local/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:44 (try_compile):
Failed to configure test project build system.
Call Stack (most recent call first):
CMakeLists.txt:15 (project)
-- Configuring incomplete, errors occurred!
See also "/home/user/project/build/CMakeFiles/CMakeOutput.log".
See also "/home/user/project/build/CMakeFiles/CMakeError.log".
CMakeOutput.log and CMakeError.log contain messages, saying that the compiler didn't find some libraries.
If I open generated file /home/user/project/build/CMakeFiles/3.15.4/CMakeSystem.cmake I can see the following
set(CMAKE_HOST_SYSTEM "Linux-4.2.0-27-generic")
set(CMAKE_HOST_SYSTEM_NAME "Linux")
set(CMAKE_HOST_SYSTEM_VERSION "4.2.0-27-generic")
set(CMAKE_HOST_SYSTEM_PROCESSOR "x86_64")
include("/home/user/project/cmake/toolchain.cmake")
set(CMAKE_SYSTEM "Generic")
set(CMAKE_SYSTEM_NAME "Generic")
set(CMAKE_SYSTEM_VERSION "")
set(CMAKE_SYSTEM_PROCESSOR "ARM")
set(CMAKE_CROSSCOMPILING "TRUE")
set(CMAKE_SYSTEM_LOADED 1)
According to CMake manual, its -D argument is used to specify cache entries.
I conclude from the output above that supplied toolchain file is processed by CMake at least 3 times. During first two times there were proper cache entries, and at the third run they were absent.
So, how can I avoid code duplication for toolchain files?
UPD. After reading this question I've tried several permutations of CMake command line parameters: specifying source path after toolchain but before options, specifying it after options, explicitly specifying source path and build path with -S and -B options. Nothing has helped.
I conclude from the output above that supplied toolchain file is processed by CMake at least 3 times. First two times there were proper cache entries, and at the third run they were absent.
Yes, this is very good observation. Technically, only the first toolchain invocation at the project() call is guarantee to see the CACHE entries (created with -D parameters to cmake or with set() commands prior to the project() call).
One approach for pass CACHE entries between the different toolchain invocations is storing them in the environment variables:
Example below uses MY_TOOLCHAIN_NAME environment variable as a storage for TOOLCHAIN_NAME CMake variable.
if(DEFINED ENV{MY_TOOLCHAIN_NAME})
# Environment variable is set.
if (TOOLCHAIN_NAME)
# CMake variable is set too.
# It is up to your which one to use.
# Uncomment line below for prefer environment variable to CMake one.
# set(TOOLCHAIN_NAME $ENV{MY_TOOLCHAIN_NAME})
else ()
# CMake variable is not set. Use environment one.
set(TOOLCHAIN_NAME $ENV{MY_TOOLCHAIN_NAME})
endif()
else()
# Environment variable is not set.
if (TOOLCHAIN_NAME)
# But CMake variable is set.
# Store it into the environment and use it.
set(ENV{MY_TOOLCHAIN_NAME} ${TOOLCHAIN_NAME})
else()
# Neither environment nor CMake variable is set.
message(SEND_ERROR "Please specify toolchain name in -DTOOLCHAIN_NAME parameter")
endif()
endif()
If you have several "tuning" variables, you may write a macro for all above steps and apply(call) this macro for every variable you need.
I have written a tutorial project whilst trying to understand the use of run-path dependent libraries on macOS and Linux. simpleapp depends on libmymaths, which in turn depends on libfastmatrix. libmymaths is a run-path dependent library and you can see the structure of the project here. I am trying to use the OS specific macros (#executable_path for macOS and $ORIGIN for linux) in order to allow the binaries to be easily moved around without breaking, since their location is going to be resolved during run-time and substituted in the macros. However, although what I've programmed so far works nicely on macOS, it doesn't on Linux. Specifically, I'm getting the following error during the linking stage of simpleapp (you can reproduce simply with ./run.sh):
/usr/bin/ld: warning: libfastmatrix.so, needed by /home/thomas/Developer/rpath_tutorial/libmymaths/libmymaths.so, not found (try using -rpath or -rpath-link)
In libmymaths' CMakeLists.txt I specify the rpath where its dependency (libfastmatrix) can be found, and that's verifiable with ldd libmymaths.so once libmymaths is built.
if(APPLE)
set(TOKEN "#loader_path")
elseif(UNIX AND NOT APPLE)
set(TOKEN "$ORIGIN")
endif()
set_target_properties(${PROJECT_NAME} PROPERTIES
CXX_STANDARD 11
CXX_EXTENSIONS FALSE
BUILD_WITH_INSTALL_RPATH TRUE
INSTALL_NAME_DIR "#rpath" # Necessary prior CMP0042 introduction.
INSTALL_RPATH "${TOKEN}/../libfastmatrix"
)
I have implemented the ld's suggestions as Fix 1 and Fix 2 in simpleapp's main CMake script, which allows the project to build.
# # Fix 1, -rpath-link (linux-specific ld option)
# LINK_FLAGS "-Wl,-rpath-link,${CMAKE_CURRENT_SOURCE_DIR}/../libfastmatrix/"
# # Fix 2, additional (unecessary for macOS) rpath, overwrites line 47
# INSTALL_RPATH "${TOKEN}/../libmymaths;${CMAKE_CURRENT_SOURCE_DIR}/../libfastmatrix"
However, this is against what I'm trying to achieve - make each library responsible for its own dependencies and not contaminate other projects with dependencies of dependencies.
1) What changes do I need to make to achieve my goal on Linux as I have done on macOS?
2) In case this is not feasible because the whole approach I am taking is incorrect, can you provide some proof or sources where this is documented?
I'm using:
CMake 3.5.1
ld 2.26.1
gcc 5.4.0
Thanks.
I do this with my game project. Here are the steps I use to make it work.
cmake_minimum_required(VERSION 3.5)
if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_INSTALL_RPATH "$ORIGIN/lib/:$$ORIGIN/lib/")
endif()
if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
install(TARGETS SpeedBlocks DESTINATION ${PROJECT_SOURCE_DIR}/build)
endif()
Note that I'm using a higher CMAKE version, so could be a bit different from what you need to do in 2.8.
After this I need to build the project, then run make install. The built binary will not have the RPATH set properly, but when I run make install (which basically just copies the binary and applies the RPATH from what I can tell) it gets set properly.
You can check if a binary has RPATH set properly by using
objdump -x path_to_binary_or_lib | grep RPATH
should output something like
RPATH $ORIGIN/lib/:$$ORIGIN/lib/:/usr/local/lib