![]() On Linux $ORIGIN represents at runtime the location of the executable and thus if set the RPATH to for example $ORIGIN/lib/libmylib.so, your executable will look for the needed shared library relative to the executable location. For that you get $ORIGIN on Linux and / / on macOS. In a lot of cases and for maximum portability, you don’t want to specify an absolute path to the shared library, but have it relative to the executable. Unfortunately, the concept gets a bit more tricky, as there are some differences between Linux and macOS. With RPATH you can solve this issue by embedding additional search paths directly into the executable. However, in case you want to ship the shared library file with your executable or have multiple versions installed in parallel, you need to make sure, that the library can be found at your custom location. In most cases the library would be placed in a common system library path and the executable would find it due to a predefined list of places to search. When you link a shared library ( *.so on Linux or *.dylib on macOS), your executable needs to somehow know, where to look for said library at runtime. For those in the same boat, I want to share some of my newfound knowledge and of course also link to the resources which helped me better understand this topic. It may very well be that this is common knowledge among Linux enthusiasts, but for me, as a Windows user, it took quite a while to fully understand the concept of RPATH ( Run-time Search Path).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |