New: rpath $ORIGIN useless when path contains colon

http://bugzilla.kernel.org/show_bug.cgi?id=15111

Summary: rpath $ORIGIN useless when path contains colon
Product: Process Management
Version: 2.5
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Preemption
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

I am trying to embed Python into the Source (Half-Life 2) game engine. Many game server providers place servers in paths containing colons (e.g., /home/srcds/93.76.8.1:27015/). Because of the way my program is called in (it is a shared library), the search path does not include the directory my shared library is in. Thus, I must use an RPATH and the RPATH variable $ORIGIN, which expands to the directory my shared library is in.

Unfortunately, when $ORIGIN is expanded, it contains a colon, and the runtime linker treats it as two individual paths, searching in "/home/srcds/93.76.8.1" and "27015/". The game server providers do not allow access to the directory where the server is run, so it is inconvenient to place the python25.so there.

To reproduce this, write any old C program that requires an external library, and compile it with the following rpath option:
-Wl,--rpath,\$$ORIGIN/relative/path/to/library

Place the executable in a path containing colons, and the external library under the directory at the location you specified. When you run the program, it will not be able to locate the external library.

Quoted 7 lines

I am trying to embed Python into the Source (Half-Life 2) game engine. Many game server providers place servers in paths containing colons (e.g., /home/srcds/93.76.8.1:27015/). Because of the way my program is called in (it is a shared library), the search path does not include the directory my shared library is in. Thus, I must use an RPATH and the RPATH variable $ORIGIN, which expands to the directory my shared library is in.

Quoted 4 lines

Unfortunately, when $ORIGIN is expanded, it contains a colon, and the runtime linker treats it as two individual paths, searching in "/home/srcds/93.76.8.1" and "27015/". The game server providers do not allow access to the directory where the server is run, so it is inconvenient to place the python25.so there.