On Wed, Feb 11, 2015 at 5:27 AM, Andrew Haley <a...@redhat.com> wrote: > 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. > Neither do I...hence my confusion. Even more so because neither this nor Linux are systems I usually work with.
I have an idea of what may be the problem, but it's just a guess, given my rudimentary understanding of how the linker, shared and dynamic libraries work. The original libfakechroot was cross-compiled to link against the system libc, and not the system libdl....hence libdl not being found. The experiments I did with libfakechroot linked the sysroot libdl and not the system libdl, therefore all dlopen() calls went straight to the system libdl, bypassing the fakechroot environment. Does that sound plausible? Cyd
