Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
Daniel Jacobowitz writes: On Wed, May 09, 2007 at 12:48:17AM +0100, James Troup wrote: (1) seems the most obvious, since h-s=both doesn't have any significant disadvantage (small amount of wasted space?) but does have the advantages of h-s=gnu. However it will require bin-only NMUs of any packages rebuilt with h-s=gnu gcc that d-i uses. I would recommend this. --hash-style=gnu is very new; I doubt readelf is the only tool that isn't ready for it. reverting back to --hash-style=both for the -7 uploads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
Daniel Jacobowitz [EMAIL PROTECTED] writes: I think it's just a bug in readelf that it can't deal with the gnu hash. IIRC it was fixed recently upstream. It hasn't been as far as I can see; there's simply no code in readelf to handle hash-style=gnu when invoked as -s -D, only for -i. I checked the mailing list and couldn't see any pending patches either. I've opened bug 4476 upstream about this[1]. In the meantime, there are only three ways to get d-i building I can see: (1) Revert the recent change to gcc and have it use hash-style=both rather than gnu. (2) Use readelf from elfutils rather than binutils in mklibs. (3) Someone (else) provides a patch for readelf to support hash for -s -D. (1) seems the most obvious, since h-s=both doesn't have any significant disadvantage (small amount of wasted space?) but does have the advantages of h-s=gnu. However it will require bin-only NMUs of any packages rebuilt with h-s=gnu gcc that d-i uses. (2) may be plausible, from casual code browsing it looks like it's readelf will at least work with h-s=gnu, but I don't know offhand if elfutils has (or even tries to have) compatible output. -- James [1] http://sourceware.org/bugzilla/show_bug.cgi?id=4476 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
On Wed, May 09, 2007 at 12:48:17AM +0100, James Troup wrote: (1) seems the most obvious, since h-s=both doesn't have any significant disadvantage (small amount of wasted space?) but does have the advantages of h-s=gnu. However it will require bin-only NMUs of any packages rebuilt with h-s=gnu gcc that d-i uses. I would recommend this. --hash-style=gnu is very new; I doubt readelf is the only tool that isn't ready for it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
The upgrade of gcc from 4.1.2-4 to 4.1.2-5 is breaking builds of the installer. The problem seems to be that a stripped library no longer contains dynamic symbol information. [...] It seems to only generate a gnu hash now. Looking at the difference in sections between -4 and -5, .hash got replaced by a .gnu.hash section. I think it's just a bug in readelf that it can't deal with the gnu hash. Any ETA on a solution for this? ATM almost all Debian Installer builds are failing because of this issue. We really need this fixed in unstable. Cheers, FJP pgpzjGa975xAi.pgp Description: PGP signature
Processed: Re: Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
Processing commands for [EMAIL PROTECTED]: reassign 421790 binutils Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries Bug reassigned from package `gcc-4.1' to `binutils'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
reassign 421790 binutils thanks On Thu, May 03, 2007 at 02:04:17PM -0400, Daniel Jacobowitz wrote: On Thu, May 03, 2007 at 07:36:59PM +0200, Kurt Roeckx wrote: From the -5 changelog: * Link using --hash-style=gnu/both. It seems to only generate a gnu hash now. Looking at the difference in sections between -4 and -5, .hash got replaced by a .gnu.hash section. I assumed from the changelog that it would be using both, but that doesn't seem to be the case. I think it's just a bug in readelf that it can't deal with the gnu hash. IIRC it was fixed recently upstream. As this just seems to be a bug in readelf, this bug belongs to binutils. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
On Tue, May 01, 2007 at 04:30:57PM +0200, Frans Pop wrote: With 4.1.2-5, the last command results in: Dynamic symbol information is not available for displaying symbols. With 4.1.2-4, the last command results in: Symbol table for image: Num Buc:Value Size Type Bind Vis Ndx Name 993 0: 000be898 4 OBJECT GLOBAL DEFAULT 26 __ctype32_b 946 0: 0004f840 932FUNC GLOBAL DEFAULT 10 execvp 972 1: 00082ff0 889FUNC GLOBAL DEFAULT 10 _dl_addr 367 1: 0004ff40 8FUNC GLOBAL DEFAULT 10 getpgrp 781 2: 309FUNC GLOBAL DEFAULT UND ___tls_get_addr 385 2: 00078fa051FUNC GLOBAL DEFAULT 10 pthread_setcancelstate [...] From the -5 changelog: * Link using --hash-style=gnu/both. It seems to only generate a gnu hash now. Looking at the difference in sections between -4 and -5, .hash got replaced by a .gnu.hash section. I assumed from the changelog that it would be using both, but that doesn't seem to be the case. I think it's just a bug in readelf that it can't deal with the gnu hash. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
On Thu, May 03, 2007 at 07:36:59PM +0200, Kurt Roeckx wrote: From the -5 changelog: * Link using --hash-style=gnu/both. It seems to only generate a gnu hash now. Looking at the difference in sections between -4 and -5, .hash got replaced by a .gnu.hash section. I assumed from the changelog that it would be using both, but that doesn't seem to be the case. I think it's just a bug in readelf that it can't deal with the gnu hash. IIRC it was fixed recently upstream. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
Package: gcc-4.1 Version: 4.1.2-5 Severity: critical Tags: d-i The upgrade of gcc from 4.1.2-4 to 4.1.2-5 is breaking builds of the installer. The problem seems to be that a stripped library no longer contains dynamic symbol information. I've traced this to the following series of commands, which are executed by mklibs (first command simplified; full command attached): gcc -nostdlib -nostartfiles -shared -Wl,-soname=libc.so.6 -uloads of symbols \ -o ./tmp/netboot/tree/lib/libc.so.6-so \ /usr/lib/libc_pic/soinit.o /usr/lib//libc_pic.a /usr/lib/libc_pic/sofini.o /lib//ld-linux.so.2 \ -Wl,--version-script=/usr/lib//libc_pic.map -lgcc -L./tmp/netboot/tree/lib -L./tmp/netboot/tree/usr/lib -L./tmp/netboot/udeblibs -L/lib/ -L/usr/lib/ -L/usr/X11R6/lib/ -L./tmp/netboot/tree//usr/lib/cdebconf objcopy --strip-unneeded -R .note -R .comment ./tmp/netboot/tree/lib/libc.so.6-so ./tmp/netboot/tree/lib/libc.so.6-so-stripped readelf -s -D -W ./tmp/netboot/tree/lib/libc.so.6-so-stripped With 4.1.2-5, the last command results in: Dynamic symbol information is not available for displaying symbols. With 4.1.2-4, the last command results in: Symbol table for image: Num Buc:Value Size Type Bind Vis Ndx Name 993 0: 000be898 4 OBJECT GLOBAL DEFAULT 26 __ctype32_b 946 0: 0004f840 932FUNC GLOBAL DEFAULT 10 execvp 972 1: 00082ff0 889FUNC GLOBAL DEFAULT 10 _dl_addr 367 1: 0004ff40 8FUNC GLOBAL DEFAULT 10 getpgrp 781 2: 309FUNC GLOBAL DEFAULT UND ___tls_get_addr 385 2: 00078fa051FUNC GLOBAL DEFAULT 10 pthread_setcancelstate [...] Cheers, FJP gcc -nostdlib -nostartfiles -shared -Wl,-soname=libc.so.6 -uwctomb -ufclose -ufreopen64 -ugetmntent -usleep -uiconv -uwcsncasecmp -uumask -umktime -u__fxstat -uisspace -ulocaltime -uctime_r -uiopl -ugetppid -uutime -ustrnlen -usiglongjmp -utcsetpgrp -urecvfrom -uopendir -usetrlimit -ustderr -uklogctl -usnprintf -uoptind -umemset -uwcschr -usync -usyslog -ustrcasestr -u__ctype_get_mb_cur_max -uwcrtomb -utcgetattr -ustrchrnul -uopenlog -uaccess -ugrantpt -usetlogmask -uclearenv -uioperm -umunmap -ustrtol -usetpgid -umbsinit -ufchdir -uwait -ugetgrnam -uwcwidth -usendmsg -u__cxa_atexit -usetuid -umkdir -urealloc -uhasmntopt -uunlockpt -u__strcasecmp -uselect -ugetchar -uscandir64 -urindex -uendservent -ustrdup -uisatty -utdelete -upathconf -ustatfs64 -uwcscat -ugettimeofday -uherror -uchdir -u__errno_location -ustrerror -ufnmatch -usysconf -u__res_maybe_init -uaccept -uabort -ufprintf -ustrtoll -ustrlen -ustrncat -uchroot -uclearerr -ugetgroups -ufeof -uwrite -uftw64 -uvasprintf -uopen64 -u__cxa_finalize -ugethostbyname -uioctl -uiconv_close -usetgroups -uunlink -utcgetpgrp -u__secure_getenv -upwrite -usigdelset -ubind -ustdin -u__xstat -umlockall -usetrlimit64 -ubasename -u__sigsetjmp -utcdrain -uiswalnum -uuname -ubtowc -ustrtoul -uswapoff -u__xpg_basename -uexeclp -ufwrite -utcflush -ugetpid -usetgid -upivot_root -uposix_memalign -ugetpwnam -uexecl -uhtonl -usendto -uexecv -umemchr -umkfifo -usys_siglist -uconnect -uflock -udirname -ukillpg -ushmget -uendpwent -ureboot -uunsetenv -usetsid -usprintf -u__ctype_b_loc -ustrrchr -uregexec -ugethostbyaddr -ustrcspn -uasprintf -uferror -ugetcwd -ufree -utfind -urecv -uputchar -u__strtol_internal -utimes -ugetservbyname -urand -uqsort -u__xstat64 -u__libc_start_main -umlock -uopen -ustrncpy -uusleep -ugetopt_long -untohl -usystem -ustrcasecmp -udcgettext -untohs -umemcmp -udprintf -umkstemp64 -ulisten -ugetgrgid -uswapon -ualphasort64 -ugetpriority -ufscanf -ustatfs -uvsnprintf -u__assert_fail -ustrtok_r -uwcswidth -usigfillset -ucfsetospeed -ustpcpy -ubindtextdomain -ugeteuid -ufseek -ustrptime -ugetrlimit64 -utsearch -ugetrlimit -urealpath -utolower -uindex -uglob -ustrpbrk -ualarm -upipe -ufseeko64 -usetvbuf -uscandir -ustrncasecmp -urandom -u_IO_putc -ustrtoull -ulseek64 -usetmntent -uiconv_open -ufputc -upause -ustrtok -ustrtod -ufputs -ufchmod -ucfmakeraw -udup2 -utwalk -uinet_ntop -ustrsep -ugetpgrp -uinet_ntoa -umemcpy -ufileno -uperror -usrandom -uumount -ustrncmp -umbtowc -ustrcat -ugetsockname -uclose -ujrand48 -ustrchr -ugetnetbyaddr -uregcomp -uvdprintf -ufcntl -u__lxstat64 -uinit_module -usigaction -usetsockopt -umallopt -ucloselog -ustrftime -uchmod -utoupper -upread -upoll -usigprocmask -uraise -uputs -udup -ureaddir64 -u__isnan -ufread -ustrsignal -uexecvp -umbsrtowcs -ushmctl -uexecve -umadvise -umount -ugetrusage -ugetpwuid -uvsprintf -urename -umalloc -ustdout -ugetmntent_r -usrand -upopen -uprctl -umunlock -urecvmsg -utowlower -uwaitpid -uoptarg -ulongjmp -u__ctype_tolower_loc -ucalloc -usetbuf -unl_langinfo -usetitimer -utextdomain -ufopen64 -umempcpy -ulseek -ugetpwent -umallinfo -ucfsetispeed -u__lxstat -ukill -ufflush -ummap64 -u__xmknod -usethostname -ummap -uptsname -usetenv -ulchown -u_setjmp -udelete_module -uread -udaemon -ustrstr -uctime -ufsync -umemmove
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
does the installer use glibc-2.5? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
On Tuesday 01 May 2007 22:09, Matthias Klose wrote: does the installer use glibc-2.5? Yes, it does for daily builds based on unstable (which is where this BR occurs). But that has not changed: we were already using 2.5 since before gcc-4.1 4.1.2-5. pgpTUKZc3yLLf.pgp Description: PGP signature
