=== kylem [n=kyle@cabal.ca] has joined #ubuntu-toolchain | ||
=== __keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-toolchain | ||
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #ubuntu-toolchain | ||
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #ubuntu-toolchain | ||
=== doko [n=doko@dslb-088-073-105-251.pools.arcor-ip.net] has joined #ubuntu-toolchain | ||
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus] has joined #ubuntu-toolchain | ||
=== jbailey [n=jbailey@209.217.74.66] has joined #ubuntu-toolchain | ||
jbailey | doko: Ran my box out of drive space last night, restarted the build this morning. | 03:32 |
---|---|---|
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus] has joined #ubuntu-toolchain | ||
doko | jbailey: ouch | 03:33 |
jbailey | rodarvus: Is there an #ubuntu-x channel where I should lurk before filing random bugs? =) | 03:34 |
rodarvus | yes, #ubuntu-x :) | 03:34 |
jbailey | Whee! | 03:34 |
jbailey | doko: Going into the testuite with 900MB Free this time. SHould be much better. =) | 04:27 |
jbailey | doko: Remind me, are you doing gcj-4.2 for edgy, or sticking with 4.1? | 04:48 |
doko | jbailey: didn't look too careful ... FC seems to have a backport of the gcjwebplugin patches to the 4.1 branch. Maybe I'll look at that one. | 04:50 |
jbailey | Ah, interesting. | 04:51 |
jbailey | I know that gcjwebplugin is now integrated into classpath itself upstream. | 04:51 |
=== mdz [n=mdz@studiocity-motorola-bsr1-70-36-194-85.vnnyca.adelphia.net] has joined #ubuntu-toolchain | ||
jbailey | doko: Starting glibc build with rebuilt gcc | 07:45 |
jbailey | doko: The solves the glibc build failure on ppc. | 08:41 |
doko | jbailey: so that was the a rebuilt gcc with ssp turned off? | 08:50 |
jbailey | Yeah, lemme debdiff for you. | 08:50 |
doko | hmm, strange | 08:53 |
=== jbailey [n=jbailey@209.217.74.66] has joined #ubuntu-toolchain | ||
=== pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-toolchain | ||
pitti | hi | 11:53 |
doko | hi | 11:53 |
pitti | one minute, please | 11:53 |
jbailey | Heya Martin! | 11:53 |
doko | glibc on powerpc doesn't build anymore with the ssp enabled gcc | 11:53 |
pitti | argh argh | 11:54 |
pitti | hm, it built before, didn't it? | 11:54 |
jbailey | pitti: Haven't had a chance to go through and really debug why, but it's an interesting problem. | 11:54 |
jbailey | glibc itself does -fstack-protector when available. | 11:54 |
pitti | right | 11:55 |
pitti | so gcc falls over if you specify -fs-p explicitly? | 11:56 |
jbailey | glibc, but yes. | 11:56 |
jbailey | It seems to cause some sort of symbol leak resulting in a link error. | 11:56 |
pitti | oh, ok, so glibc must be fixed, not gcc? | 11:57 |
pitti | jbailey: interesting, I saw a similar bug when building postgresql on sid, remember? | 11:57 |
=== pitti actually looks at build log | ||
pitti | " edgy powerpc Successfully built" | 11:58 |
pitti | hm, that won't help me | 11:58 |
jbailey | pitti: I'm not sure who's bug it is. glibc is correct for an upstream gcc and DTRT for stack protection for itself. | 11:58 |
pitti | is there any build log somewhere? | 11:58 |
doko | jbailey: when calling gcc -E, I currently do not turn on -fstack-protector, resulting in a missing __SSP__ define. but that should be consistent across architectures | 11:59 |
pitti | ouch, SSP influences -E? | 11:59 |
pitti | I thought inline functions and such were only decorated with -fstack-protector-all or oso | 12:00 |
doko | I only say, that a macro is defined. | 12:01 |
pitti | ah | 12:01 |
pitti | jbailey: so, it fails for you locally? | 12:02 |
jbailey | pitti: Yes. | 12:02 |
doko | jbailey: amd64 and i386 builds fail as well | 12:02 |
jbailey | doko: Thanks. | 12:02 |
jbailey | I didn't have much time to research it with the sprint last week. | 12:03 |
jbailey | I can try to look through it this weekend, I guess. I'm behind on so many things right now. | 12:03 |
doko | gcc-4.1 -nostdlib -nostartfiles -r -o /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/librtld.map.o '-Wl,-(' /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a -lgcc '-Wl,-)' -Wl,-Map,/home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/librtld.mapT | 12:03 |
doko | /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs' | 12:03 |
doko | /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os:(.bss+0xec): first defined here | 12:03 |
doko | /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a(_itoa.os): In function `_itoa': | 12:03 |
doko | _itoa.c:(.text+0xb0): multiple definition of `_itoa' | 12:03 |
doko | /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os:(.text+0x13960): first defined here | 12:03 |
doko | /usr/bin/ld: Warning: size of symbol `_itoa' changed from 120 in /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/elf/dl-allobjs.os to 432 in /home/packages/glibc/u/glibc-2.4/build-tree/amd64-libc/libc_pic.a(_itoa.os) | 12:03 |
pitti | jbailey: curious why it works on the buildds | 12:03 |
doko | collect2: ld returned 1 exit status | 12:03 |
doko | that is amd64 ... | 12:03 |
jbailey | pitti: It didn't. | 12:03 |
doko | pitti: we didn't try yet :) | 12:03 |
jbailey | pitti: The last glibc build on the buildds was before the forced ssp change. | 12:04 |
pitti | oh | 12:04 |
doko | gcc-4.1 -nostdlib -nostartfiles -shared -o /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/ld.so \ | 12:04 |
doko | -Wl,-z,combreloc -Wl,-z,relro -Wl,-z,defs \ | 12:04 |
doko | /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os -Wl,--version-script=/home/packages/tmp/glibc-2.4/build-tree/i386-libc/ld.map \ | 12:04 |
doko | -Wl,-soname=ld-linux.so.2 -T /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/ld.so.lds | 12:04 |
doko | /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `process_dl_debug': | 12:04 |
doko | /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/rtld.c:2452: undefined reference to `__stack_chk_fail_local' | 12:04 |
doko | /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `process_envvars': | 12:04 |
doko | /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/rtld.c:2711: undefined reference to `__stack_chk_fail_local' | 12:04 |
doko | /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `dl_main': | 12:05 |
doko | /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/rtld.c:2332: undefined reference to `__stack_chk_fail_local' | 12:05 |
doko | /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `print_search_path': | 12:05 |
doko | /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/dl-load.c:1548: undefined reference to `__stack_chk_fail_local' | 12:05 |
doko | /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os: In function `open_verify': | 12:05 |
doko | /home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/dl-load.c:1762: undefined reference to `__stack_chk_fail_local' | 12:05 |
doko | /home/packages/tmp/glibc-2.4/build-tree/i386-libc/elf/librtld.os:/home/packages/tmp/glibc-2.4/build-tree/glibc-2.4/elf/dl-load.c:1917: more undefined references to `__stack_chk_fail_local' follow | 12:05 |
doko | collect2: ld returned 1 exit status | 12:05 |
pitti | hm, that's strange -- glibc itself is shipping __stack_chk_fail() | 12:05 |
pitti | so it should have _local as well... | 12:05 |
jbailey | Right, so I'm confused by this. | 12:06 |
jbailey | Also by the need to patch in libssp into gcc itself. | 12:06 |
jbailey | vacuum coming through, bbias. | 12:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!