On 01/07/2015 01:20 PM, Brian Drummond wrote: > On Wed, 2015-01-07 at 12:17 +0000, Andrew Haley wrote: >> On 01/07/2015 12:14 PM, Cyd Haselton wrote: >>> Here goes. >> >> You mailer mangled that. As an attachment please. >> >> Andrew. >> > > Below is the relevant command I saw in the attachment (most .o filenames > redacted)... > > It ends with > fakechroot: dlopen: undefined symbol: dlopen > collect2: error: ld returned 1 exit status > make: *** [libgcc_s.so] Error 1 > > which I think reinforces your hypothesis that it is the ld program > itself which fails, rather than anything in the files being linked. > > I don't know if Cyd cc'ed you this message... > (I'll forward it to the list) > ---------------------------------------------------------------------- >> The following is a quote from the developer who created the >> environment I'm using: >> >> "Using libfakechroot to virtualize a root filesystem is a bit of a >> hack, to be honest, and its weaknesses are easily exposed. Most >> obviously, it will only filter dynamic calls to the Bionic C library >> (because that was the C library it itself is linked against). > ... >> I've been in contact with him regarding a number of other ports and >> he's confirmed that reverting to static linking would be a pain. >> >> Also, iIn case anyone reading this is interested: >> http://kevinboone.net/kbox2_how_it_works.html > ---------------------------------------------------------------------- > > which makes me wonder about Bionic's support for dlopen(). Cyd confirmed > that he uses the same binutils version for 4.8 and 4.9 so we may be > looking at a failure in a 2-step process > > (a) 4.9 assumes some capability from ld that 4.8 doesn't, which requires > a DLL to be opened > > (b) fakechroot layered over Bionic is failing to implement that > capability (we know from nm that dlopen is undefined in Cyd's > libfakechroot.so) > > Step (a) may be within the remit of gcc-help, what is the difference and > can it be worked round) but step (b) probably lies elsewhere : as a > first step, enquire about the missing dlopen() in fakechroot. I think it's now becoming clear what is happening. Something in ld is calling dlopen, and fakechroot prints the error. But it's not clear to me which dlopen does not work in fakechroot. My guess is that the problem is due to link-time optimization. gcc is trying to run -plugin /bld/gcc/builddir-4.9/./gcc/liblto_plugin.so. 4.8 does not do this. Maybe fakechroot can be persuaded to produce a decent error message with some more information. It may be possible to disable LTO. Andrew.
