(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sat, 23 Jan 2010 02:11:37 GMT bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > 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: rlove@xxxxxxxxx > ReportedBy: they4kman@xxxxxxxxx > 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. > -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
