/
> >>> So, anyone probing for dlopen() finds it in libfakechroot. >>> However, when that dlopen() is called you get a (very confusing) >>> link error. This is a bug because if the underlying C library does >>> not have dlopen() then libfakechroot should either not export it or >>> should forward calls to the right library (which was libdl.so, I >>> think.) >> >> Out of curiosity (and future libfakechroot porting purposes) how >would >> this look? I know that this and the previous question are off -topic >> to the original email so feel free to leave the list out of your >> reply. > >I'd rather leave it on-list for future reference. The best thing >would be for libfakechroot to be linked against libdl: that way, when >dlopen() was called the link would be correctly satisfied. If that >isn't possible (if dlopen() doesn't work or is incompatible) then >libfakechroot shouldn't export the symbol for dlopen(). > >Andrew. After experimenting with several builds of the fakechroot library I can't see how this would be possible. Even when libdl is linked in, hiding dlopen guarantees that the resulting library doesn't intercept dlopen calls, which breaks the fakechroot environment and removing the fakechroot dlopen code also ensures that dlopen calls aren't intercepted. Cyd -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
