I\'m trying to link an RPATH containing the special string $ORIGIN into an executable built using GCC with the Code::Blocks IDE. I\'ve specified
-Wl,-R$ORIGI
Whoever decided to make the token $ORIGIN is an evil bastard who deserves a special place in programmer hell. Since '$' is a special character for bash and other scripting languages like make, it screws everything up unless carefully escaped. Even worse, depending on which build environment you're using, the specifics of how to escape properly will likely change.
In bash, you need to stick a backslash in front of the $:
-Wl,-R\$ORIGIN
Code::Blocks apparently also treats the $ as special. Then, whatever subprocess controller Code::Blocks sends the command to treats the backslash as special. So, both the backslash and the $ need to be doubled up to get escaped properly. Therefore, in Code::Blocks linker settings, you need to specify:
-Wl,-R\\$$ORIGIN
...which outputs:
-Wl,-R\\$ORIGIN
...to the build log, but the shell actually gets sent:
-Wl,-R\$ORIGIN
...which as mentioned above produces the desired result.
What a pain.
In addition to kblucks answer that addresses the question for Code:Blocks.... For those like me who stumbled across this page looking for how to do this with Make. The trick is to use an extra $ sign as an escape character and to enclose it with quotes:
-Wl,-R,'$$ORIGIN/../lib'
Full explanation can be had here: Using ORIGIN for a dynamic runtime library search path
If your executable is being built by a huge complex script environment not created by you, and you don't want to delve into with that, trying running with setenv LD_RUN_PATH='$ORIGIN/../lib'
; if that doesn't work, a pragmatic approach is to create a wrapper for ld:
#!/bin/sh
exec /usr/bin/ld -R '$ORIGIN/../lib' "$@"
... then do the build with that stub on the path. In practice it may be called to build .so files, or other executables, so you may need to make this a more complex script that decides whether to insert the RPATH. OR, run build without this, and with, and cherry pick.
(here "/usr/bin/ld" is the ld that would normally have been run, which may be somewhere else. gcc may not pick up ld from the path, see gcc environment variables to override that. Mileage may vary. Single use only. Not warranted to be less awful than any other approach).