Re: address@hidden

[Jan Nieuwenhuizen]

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 address@hidden'

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 address@hidden:~/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 <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl