{"id":7632,"date":"2026-02-18T17:12:37","date_gmt":"2026-02-18T23:12:37","guid":{"rendered":"https:\/\/www.logikalsolutions.com\/wordpress\/?p=7632"},"modified":"2026-02-18T17:12:37","modified_gmt":"2026-02-18T23:12:37","slug":"rpath","status":"publish","type":"post","link":"https:\/\/www.logikalsolutions.com\/wordpress\/information-technology\/rpath\/","title":{"rendered":"RPATH Notes"},"content":{"rendered":"\n

Few things are more frustrating when first developing your own libraries than RPATH. There have been numerous hacks over the years. Gnu even gave us libtool<\/a> because POSIX dlopen() just kinda sucked. <\/p>\n\n\n\n

Hey, for the end user, dlopen() mostly works. It finds dynamically linked libraries in the system standard search paths, all is well with the world. For the developer working on dynamically linked libraries or worse yet, plugins that use dynamically linked libraries from the same build, it is crawling naked across broken glass.<\/p>\n\n\n\n

There is a not bad explanation in this question<\/a>. Yes, I was asking the question. You might want to read it now.<\/p>\n\n\n\n

Most of you nave seen my posts on CopperSpice<\/a> and know I currently have LsCs<\/a> as a fork. The fork will be disconnected from CopperSpice as soon as I finish my cleanup experiments. Product will also be branded LsX at that time as well. Current working branch is 0.2.1 but that is subject to change.<\/p>\n\n\n\n

.conf Never Worked<\/h2>\n\n\n\n

One of the more insidious problems was the fact qt.conf<\/a> never worked. Believe me, I fought this unwinnable battle both times I worked on the IPOS project for different Publicis Groupe<\/a> agencies. We didn’t have things like flatpak then. I had to build a .deb that would install (and cleanly un-install) a captive user account for one of those Explore This Computer<\/em> applications you see running in big box stores.<\/p>\n\n\n\n

Take a look at the current list of entries for qt.conf<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Admittedly the Plugins entry has limited success, but Libraries is a complete farce. <\/p>\n\n\n\n

What Happens When You Run An Executable?<\/h2>\n\n\n\n

dlopen() bites you in the ass.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

First, dlopen() operates differently on every OS family. Linux distros mostly work the same, but Mac and QNX are different. I would expect WindRiver and other “Linux-like” RTOS implementations to be different as well. Here is where you really need to take a moment and read the previously linked discussion<\/a>. <\/p>\n\n\n\n

Your ELF<\/h3>\n\n\n\n

Assuming you haven’t statically linked Gnu libtool and had an init() procedure pre-load every one of your custom library files pointed to by the Libraries entry, dlopen() will follow the above mentioned search paths. the first search path with be RPATH or RUNPATH baked into your ELF.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

For those who just want a command to scrape<\/p>\n\n\n\n

<\/circle><\/circle><\/circle><\/g><\/svg><\/span>