On Wed, Jan 7, 2015 at 7:37 AM, Andrew Haley <aph@xxxxxxxxxx> wrote: > 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. > This is probably a stupid question, but here goes: How many dlopens are there? > 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. I doubt it. The fakechroot running the environment hasn't been updated since it was built, due to the developer's understandable reluctance to update a key part of the environment. I've thought about building a later version...have even downloaded the source...but was holding off until I'd updated a few other things. It may be time to take another look. > > It may be possible to disable LTO. Between updating fakechroot and this, this would be the easier option. Would it be done through configure? > > Andrew. >
