On 02/11/2015 10:00 AM, Cyd Haselton wrote: > > > On February 11, 2015 2:36:59 AM CST, Andrew Haley <a...@redhat.com> wrote: >> On 11/02/15 00:41, Cyd Haselton wrote: >>> >>>> >>>> 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(). >>> >>> 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. >> >> I don't get it. If libdl is linked in, why would you hide dlopen() ? > > libdl was linked in the original, buggy libfakechroot...the one that exported > dlopen().
But if it was linked in, where did the dlopen() link error come from? It should have succeeded because dlopen() should have been found in libdl. I still don't get it. Andrew.
