Bug 10253 - RPATH $ORIGIN breaks if resulting path has colons in it
: RPATH $ORIGIN breaks if resulting path has colons in it
Status: NEW
Product: glibc
Classification: Unclassified
Component: dynamic-link
: unspecified
: P2 critical
: ---
Assigned To: Not yet assigned to anyone
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-06-08 04:52 UTC by Gerry
Modified: 2012-12-19 10:46 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Script to reproduce bug (785 bytes, text/plain)
2009-06-08 04:53 UTC, Gerry
Details
quick fix (2.74 KB, patch)
2010-01-24 09:29 UTC, Zach Kanzler
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gerry 2009-06-08 04:52:07 UTC
As the summary says, RPATH with $ORIGIN breaks if the expansion of ORIGIN 
results in a path with colons in it.  More specifically, the path is broken up 
at the colons.

For example, if an executable has RPATH set to $ORIGIN, requires a library 
(libfoo.so) that is in the same directory as the exceutable, and both files 
reside in eg /tmp/a, everything will work fine.  However, if both files reside 
in /tmp/a:b (and not in /tmp/a), the linker will be unable to find libfoo.so.  
If the executable is in /tmp/a:b but libfoo.so exists in /tmp/a, the linker 
will find /tmp/a/libfoo.so in stead of the one in the executable's directory.

I've tested this on Arch Linux 64-bit with glibc 2.10.1, and also on Gentoo 
Linux 32-bit with glibc 2.4.  The results are identical on both systems.

I'll attach a script that illustrates the bug.
Comment 1 Gerry 2009-06-08 04:53:13 UTC
Created attachment 3987 [details]
Script to reproduce bug

Run the attached script to reproduce.  It'll create a new directory named
rpath-bug, enter it, and compile a small library named libfoo.so and an
executable with RPATH set to '$ORIGIN'.  Then it'll copy the files around to a
couple subdirectories with or without colons, showing results of ldd etc.

Here's the output I get when running the script in /tmp:

=== /tmp/rpath-bug ===
* ls:		      
foo.c  libfoo.so  test	test.c	this  this:breaks:rpath
* ./test:					       
* objdump -x test | grep RPATH: 		       
  RPATH 	       $ORIGIN			       
* ldd test:					       
	linux-vdso.so.1 =>  (0x00007fff3e1fe000)       
	libfoo.so => /tmp/rpath-bug/libfoo.so (0x00007fd535c83000)
	libc.so.6 => /lib/libc.so.6 (0x00007fd53592e000)	  
	/lib/ld-linux-x86-64.so.2 (0x00007fd535e84000)		  

=== /tmp/rpath-bug/this:breaks:rpath ===
* ls:					
libfoo.so  subdir  test 		
* ./test:				
./test: error while loading shared libraries: libfoo.so: cannot open shared
object file: No such file or directory
* objdump -x test | grep RPATH: 					       
				  
  RPATH 	       $ORIGIN						       
				  
* ldd test:								       
				  
	linux-vdso.so.1 =>  (0x00007fffff7ff000)			       
				  
	libfoo.so => not found						       
				  
	libc.so.6 => /lib/libc.so.6 (0x00007f13f70ef000)		       
				  
	/lib/ld-linux-x86-64.so.2 (0x00007f13f7444000)			       
				  

=== /tmp/rpath-bug/this:breaks:rpath/subdir ===
* ls:					       
libfoo.so  test 			       
* ./test:				       
./test: error while loading shared libraries: libfoo.so: cannot open shared
object file: No such file or directory
* objdump -x test | grep RPATH: 					       
				  
  RPATH 	       $ORIGIN						       
				  
* ldd test:								       
				  
	linux-vdso.so.1 =>  (0x00007ffff23fe000)			       
				  
	libfoo.so => not found						       
				  
	libc.so.6 => /lib/libc.so.6 (0x00007ff9e9dbd000)		       
				  
	/lib/ld-linux-x86-64.so.2 (0x00007ff9ea112000)

* back to this:breaks:rpath

«libfoo.so» -> «breaks/libfoo.so»

=== /tmp/rpath-bug/this:breaks:rpath ===
* ls:
breaks	libfoo.so  subdir  test
* ./test:
* objdump -x test | grep RPATH:
  RPATH 	       $ORIGIN
* ldd test:
	linux-vdso.so.1 =>  (0x00007fffb91ff000)
	libfoo.so => breaks/libfoo.so (0x00007fd3b0d5c000)
	libc.so.6 => /lib/libc.so.6 (0x00007fd3b0a07000)
	/lib/ld-linux-x86-64.so.2 (0x00007fd3b0f5d000)

«libfoo.so» -> «../this/libfoo.so»

=== /tmp/rpath-bug/this:breaks:rpath ===
* ls:
breaks	libfoo.so  subdir  test
* ./test:
* objdump -x test | grep RPATH:
  RPATH 	       $ORIGIN
* ldd test:
	linux-vdso.so.1 =>  (0x00007fff00bfe000)
	libfoo.so => /tmp/rpath-bug/this/libfoo.so (0x00007f51f87d0000)
	libc.so.6 => /lib/libc.so.6 (0x00007f51f847b000)
	/lib/ld-linux-x86-64.so.2 (0x00007f51f89d1000)

=== /tmp/rpath-bug/this:breaks:rpath/subdir ===
* ls:
libfoo.so  test
* ./test:
* objdump -x test | grep RPATH:
  RPATH 	       $ORIGIN
* ldd test:
	linux-vdso.so.1 =>  (0x00007fffb11ff000)
	libfoo.so => /tmp/rpath-bug/this/libfoo.so (0x00007f71a8c42000)
	libc.so.6 => /lib/libc.so.6 (0x00007f71a88ed000)
	/lib/ld-linux-x86-64.so.2 (0x00007f71a8e43000)
Comment 2 Zach Kanzler 2010-01-24 09:29:16 UTC
Created attachment 4552 [details]
quick fix

I've created a quick patch that solves the issue. I've tested it against the
git master.
Comment 3 Andy Lutomirski 2011-11-21 22:22:07 UTC
Any chance of getting this fixed?  I just triggered it in a production system
(oops!)
Comment 4 Siddhesh Poyarekar 2012-10-23 09:00:40 UTC
(In reply to comment #2)
> Created attachment 4552 [details]
> quick fix
> 
> I've created a quick patch that solves the issue. I've tested it against the
> git master.

Please post your patch on the libc-alpha mailing list for review from the
maintainers.  You'll need to follow the guidelines here:

http://sourceware.org/glibc/wiki/Contribution%20checklist

Please remove the "ADDED BY THEY4KMAN " lines in the patch and remove code
instead of commenting it out.