[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden
From: |
Jan Nieuwenhuizen |
Subject: |
Re: address@hidden |
Date: |
Tue, 28 Jun 2011 11:18:46 +0200 |
User-agent: |
Gnus/5.110016 (No Gnus v0.16) Emacs/23.3 (cygwin) |
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
- address@hidden, Graham Percival, 2011/06/27
- Re: address@hidden,
Jan Nieuwenhuizen <=