BusyBox Bug and Patch Tracking
BusyBox
Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ View Advanced ] [ Issue History ] [ Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000060 [uClibc] Architecture Specific minor always 01-24-05 20:09 08-02-05 20:13
Reporter psm View Status public  
Assigned To uClibc
Priority normal Resolution fixed  
Status closed   Product Version
Summary 0000060: LD_LIBRARY_PATH fails if ":<somepath>"
Description if LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:<somepath>" is used, and the initial
LD_LIBRARY_PATH was empty, the path becomes LD_LIBRARY_PATH=":<somepath>", and
that is not accepted by uclibc (glibc tolerates that)
Additional Information
Attached Files  ld_lib_path.patch [^] (1,346 bytes) 05-25-05 06:35
 ld_lib_path_2.patch [^] (1,363 bytes) 05-25-05 06:44
 ld_lib_path_3.patch [^] (1,644 bytes) 05-27-05 01:17

- Relationships

- Notes
(0000209)
scott
05-24-05 14:46

 also, if LD_LIBRARY_PATH ends with ":" it will look in the CWD. So, it would seem then ending the path with ":" is the same as ":."

only after removing the ":" from the last character in the path does the loader then stop looking in cwd for libs.

To reproduce this, change your LD_LIBRARY_PATH to have ":" as the last character, then cd into a different /usr/lib (compile glibc or uclibc for another version) and /bin/ls will break.
 
(0000210)
vapier
05-24-05 15:39

 what do you mean by 'not accepted' ?

also, glibc treats an empty path as meaning '.' ... also, i cant really reproduce the behavior you describe ...

i exported LD_LIBRARY_PATH=: and then tried `ls` in $HOME, /lib, and /usr/lib ... this worked fine in both uClibc-0.9.27 and glibc
 
(0000211)
jocke
05-25-05 06:35

 Does ld_lib_path.patch solve anything. I havn't tested it.
 
(0000212)
jocke
05-25-05 06:44

 Oops, small bug. Use ld_lib_path_2.patch instead
 
(0000213)
psm
05-26-05 08:54

 path_2 patch makes it worse, now LD_LIBRARY_PATH isn't interpreted at all
the syntax that fails is:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:somepath
if LD_LIBRARY_PATH was empty
using LD_LIBRARY_PATH=somepath
is ok
 
(0000214)
vapier
05-26-05 10:24

 in case i'm not the only one who didnt understand the situation ...

if you set LD_LIBRARY_PATH=:/blah then uClibc will not search in the addtional custom /blah path
 
(0000215)
jocke
05-27-05 01:18

 Vapier, you were not the only one ..
How about ld_lib_path_3.patch?
 
(0000219)
psm
05-29-05 23:35

 the last solved my problem
 
(0000221)
jocke
05-31-05 04:49

 Fixed in SVN
 

- Issue History
Date Modified Username Field Change
01-24-05 20:09 psm New Issue
03-16-05 11:54 andersen Assigned To andersen => uClibc
05-24-05 14:46 scott Note Added: 0000209
05-24-05 15:39 vapier Note Added: 0000210
05-25-05 06:35 jocke File Added: ld_lib_path.patch
05-25-05 06:35 jocke Note Added: 0000211
05-25-05 06:44 jocke File Added: ld_lib_path_2.patch
05-25-05 06:44 jocke Note Added: 0000212
05-26-05 08:54 psm Note Added: 0000213
05-26-05 10:24 vapier Note Added: 0000214
05-27-05 01:17 jocke File Added: ld_lib_path_3.patch
05-27-05 01:18 jocke Note Added: 0000215
05-29-05 23:35 psm Note Added: 0000219
05-31-05 04:49 jocke Status assigned => closed
05-31-05 04:49 jocke Note Added: 0000221
06-10-05 15:31 jocke Status closed => resolved
06-10-05 15:31 jocke Resolution open => fixed
08-02-05 20:13 andersen Status resolved => closed

Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker