Graham Percival writes: Hi Graham,
> GUB, using the release-2.14 branch, dies on > linux-x86::lilypond-doc. Apparently our docs now contain > something which uses a code path which we never used before? I don't think so. > This discussion: > http://stackoverflow.com/questions/5090881/libgcc-s-so-undefined-reference-to-stack-chk-failglibc-2-4 Yeah... of course, we have two libc's one in /lib and one in GUB. The one in GUB is very old (2.3.x) and does not have the stack protector feature. > /main/src/gub/target/tools/root/usr/lib/libltdl.so.7: undefined > reference to `__stack_chk_fail@GLIBC_2.4' You should find out what command that is. I don't fully understand what's happening here. The command is using GUB's libc. Strangly, it looks like it could be python. In that case, you could check by doing something like LD_LIBRARY_PATH=$HOME/vc/gub/target/linux-x86/root/usr/lib ldd target/linux-x86/root/usr/bin/python Could it be that your python is statically linked? The command that needs the stack protector should have its .spec fixed (or a patch be added) to switch off the usage of stack protector. Try 10:09:12 janieuwe@PC201668:~/vc/gub $ git grep protector gub/specs/bzip2.py: compile_flags = ''' -f Makefile-libbz2_so CC='%(toolchain_prefix)sgcc %(target_gcc_flags)s -fno-stack-protector' ''' to get an idea of how that works Jan -- Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
