On 01/02/2015 10:32 AM, Cyd Haselton wrote: > On Fri, Jan 2, 2015 at 3:11 AM, Andrew Haley <aph@xxxxxxxxxx> wrote: >> On 01/01/15 22:51, Cyd Haselton wrote: >>>> /android_root/system/bin/sh ./libtool --tag=CC --tag=disable-static >>>>> --mode=link gcc --sysroot=/usr/gcc-4.8.4/sysroot -Wall -Wall -O >>>>> -mandroid -mbionic -module -bindir >>>>> /usr/gcc-4.8.4/libexec/gcc/arm-linux-androideabi/4.8.4 >>>>> -static-libstdc++ -static-libgcc >>>>> -Wl,--dynamic-linker=/system/bin/linker -lc -ldl -lgcc -lm -o >>>>> liblto_plugin.la -rpath >>>>> /usr/gcc-4.8.4/libexec/gcc/arm-linux-androideabi/4.8.4 lto-plugin.lo >>>>> -Wc,../libiberty/pic/libiberty.a >>>>> >>>>> There were others, but I'll hold off including them unless the above >>>>> are not relevant to my issue. >>> Polite bump just in case reply was missed. >>> >>> Since the above post I've tried replacing the -static-libgcc reference >>> in the top level Makefile with -shared-libgcc (which results in a slew >>> of errors), specifying the stage1, boot and poststage1 libs in the >>> Makefile with the same libs specified in configure (which doesn't >>> work) and adding the same options from the LDFLAGS I specified in the >>> top-level configure to the post stage1 LDFLAGS and stage1 LDFLAGS. No >>> success so far. >>> >>> I still have the build logs from 4.8 and 4.9...I can upload them if >>> they would be of use in diagnosing this issue. >> >> Tell us the command which failed and the command which succeeded and >> the output. We can then look at the difference. We're not >> clairvoyant! > > Didn't say that anyone was. > > None of the "commands" succeeded Yes they did. You already told us that 4.8 built. > and the output is the same as in the original problem. Building the > shared libgcc in 4.9.2 fails with undefined reference to dlopen. > This succeeds in 4.8.4 but there is no info that I can see in the > build l9gs I captured that indicates why Okay, so if the commands are identical you need to run them by hand in the correct directory to see what is different. if the command which failed in 4.9 is exactly the same as the command which succeeded in 4.8 its input files must be different, and in particular dlopen() must be defined in one of the input files or the user of dlopen() must not be there in 4.8. You have this information in your build: one or the other of these must be true. Andrew.
