pitti | hm, so it seems that glibc wants to build some parts of it without ssp | 12:09 |
---|---|---|
doko | jbailey: no, libssp0 isn't really used, I should not build it, if we build on a glibc-2.4 based system | 12:09 |
pitti | doko: hm, am I right that using something like "CC=gcc-4.1 -fno-stack-protector" should be exactly equivalent to the state gcc-4.1 was when it built the current glibc? | 12:10 |
pitti | doko: then glibc would add -fstack-protector when it actually wants it, and for the cases it doesn't explicitly add it we would get the non-ssp behaviour again | 12:11 |
doko | pitti: yes, that should do it | 12:11 |
pitti | ok, worth a try in any case. I'll start a test build now, it should finish by the end of the meeting | 12:12 |
pitti | 'k, I modified debian/rules, running now | 12:15 |
doko | pitti: powerpc? | 12:37 |
pitti | no, amd64 | 12:39 |
pitti | <doko> jbailey: amd64 and i386 builds fail as well | 12:40 |
pitti | ^ so testing on amd64 should be fine? | 12:40 |
pitti | my laptop still runs dapper, and would take ages anyway | 12:40 |
pitti | if I should test it on powerpc, I'll rather request the b-deps on davis | 12:40 |
doko | pitti, jbailey: amd64 build using -fno-stack-protector succeeded | 12:40 |
pitti | oh, they are there (the b-deps) on davis, how convenient | 12:41 |
pitti | doko: ok, then your build was way faster | 12:41 |
pitti | doko: I start a ppc test build now if you want me to | 12:42 |
pitti | doko: on my amd64, I changed CC, but changing {BUILD,HOST}_CFLAGS should work as well; what did you use? | 12:42 |
pitti | ok, ppc test build with 'CC=gcc-4.1 -fno-stack-protector' is running | 12:43 |
pitti | jbailey: indeed most of the files in glibc are *not* build with explicit -fstack-protector; only 48 of them | 12:44 |
pitti | so maybe upstream saw the same problem and is only gradually enabling it, who knows | 12:44 |
pitti | hm, amd64 failed for me | 12:55 |
pitti | when building the i386 version | 12:55 |
pitti | checking for forced unwind support... no | 12:55 |
pitti | configure: error: forced unwind support is required | 12:55 |
pitti | also, | 12:56 |
pitti | checking for -fstack-protector... no | 12:56 |
pitti | ^ for the i386 build | 12:56 |
pitti | the amd64 build worked fine | 12:56 |
=== Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-toolchain | ||
pitti | jbailey: hm, powerpc fails as well, but due to a completely unrelated issue | 01:02 |
pitti | ../sysdeps/unix/sysv/linux/powerpc/sys/procfs.h:56: error: conflicting types for 'elf_vrreg_t' | 01:02 |
pitti | /home/pitti/glibc/glibc-2.4/debian/include/asm/elf.h:153: error: previous declaration of 'elf_vrreg_t' was here | 01:02 |
pitti | and similar errors before that | 01:02 |
doko | i386 works fine for me as well ... | 01:03 |
pitti | hmm | 01:04 |
doko | I have a slightly newer compiler version, but I doubt that changes anything | 01:06 |
pitti | certainly not wrt that double declaration | 01:06 |
pitti | maybe the davis chroot has an older compiler version | 01:06 |
doko | no, I asked for dist-upgrades this or last week | 01:08 |
pitti | hm, indeed it's the last version | 01:08 |
jbailey | pitti: Right, that's a conflict in lkh tha tI need to work around, but that's easy enough. | 01:16 |
jbailey | Sorry about the lag, had a meeting. | 01:16 |
doko | jbailey: both i386 and amd64 build with -fno-stack-protector. cannot check the powerpc build. | 02:50 |
doko | so it looks the outstanding issue is still long-double-128 ... | 02:51 |
jbailey | Right, ppc I can get to build base don what I've seen | 02:51 |
jbailey | I haven't looked much into the ldbl-128 stuff. My understanding was that there were supposed to be compat symbols and handling for pre-stuff. | 02:54 |
jbailey | Is that not the case? | 02:54 |
doko | jbailey: no, take the libstlport4.6 from dapper, and try to link with it on a current edgy (I rebuilt libstlport4.6 this week, so you won't see it with the edgy stlport) | 02:56 |
jbailey | Cool, thanks. | 02:57 |
=== chmj [n=chmj@196.44.1.98] has joined #ubuntu-toolchain | ||
=== doko [n=doko@dslb-088-073-095-026.pools.arcor-ip.net] has joined #ubuntu-toolchain | ||
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus] has joined #ubuntu-toolchain | ||
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus] has joined #ubuntu-toolchain | ||
rodarvus | hi | 03:24 |
rodarvus | I just received a bug report on xserver-xorg-input-synaptics -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/ | 03:24 |
rodarvus | dlopen: /usr/lib/xorg/modules/input/synaptics_drv.so: undefined symbol: __stack_chk_fail_local | 03:24 |
rodarvus | can this bug be somehow related to the stack protection changes which happened recently? | 03:25 |
=== pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-toolchain | ||
pitti | hi | 03:42 |
rodarvus | hi pitti | 03:43 |
rodarvus | I just reported an (apparent) crash on xserver-xorg-input-synaptics here - do you want me to paste it to you in a private window? | 03:43 |
rodarvus | (there) | 03:44 |
doko | rodarvus: now you can try again ... ;-) | 03:45 |
pitti | yep, got it | 03:45 |
rodarvus | doko, thanks :) | 03:46 |
=== freeflying [n=freeflyi@ubuntu/member/freeflying] has joined #ubuntu-toolchain | ||
=== freeflying [n=freeflyi@ubuntu/member/freeflying] has left #ubuntu-toolchain ["Konversation] | ||
pitti | rodarvus: hm, I have no clue where __stack_chk_fail_local() is defined | 03:49 |
=== jbailey [n=jbailey@209.217.74.66] has joined #ubuntu-toolchain | ||
pitti | rodarvus: maybe the bst option is to build with -fno-stack-protector for now and keep a record of this in the SSP spec? | 03:49 |
rodarvus | sure, I'll do it | 03:50 |
rodarvus | I'll also ask ogra to test it to me before uploading, just to make sure all is fine | 03:50 |
jbailey | pitti: Do you know what order command line arguments take precidence? I'm wondering if for glibc if I can do "gcc -fno-stack-protector", and still have it enabled on the files it wants by having it add it later in the command line itself. | 03:50 |
jbailey | I'll try it a bit later. I have a couple urgent things first. | 03:51 |
pitti | jbailey: yes, last one wins | 03:51 |
doko | jbailey: you could check, if the __SSP__ macro is defined. but IIRC the last one wins | 03:51 |
jbailey | Nice. I'll try that for the glibc builds then. | 03:51 |
pitti | jbailey: yesterday's test build went well with 'CC=gcc-4.1 -fno-stack-protector' | 03:52 |
pitti | jbailey: apart from the duplicate symbol on powerpc that I pasted | 03:52 |
pitti | rodarvus: ok, I add it to the wiki page so that we have a reference | 03:52 |
pitti | rodarvus: is there an LP bug for it? | 03:52 |
jbailey | Duplicate symbol? | 03:53 |
jbailey | You mean the elf_vrrg_reg thing? | 03:53 |
pitti | might be, yes | 03:53 |
rodarvus | pitti, yes bug 54357 | 03:53 |
rodarvus | pitti -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/ | 03:54 |
pitti | rodarvus: ok, I added it to https://wiki.ubuntu.com/GccSsp | 03:55 |
jbailey | pitti: 'kay. I'll run it... | 03:56 |
jbailey | or maybe I won't since my machine at home isn't on. | 03:56 |
jbailey | X bug that I filed earlier this morning. *sigh* | 03:56 |
rodarvus | pitti, nice, thanks! | 03:56 |
jbailey | So it'll be tonight when I get home to roll back X. | 03:56 |
pitti | jbailey: use a DC porter machine? | 03:56 |
rodarvus | jbailey, I didn't saw this bug | 03:56 |
rodarvus | let me check | 03:56 |
rodarvus | jbailey, apparently x-swat was not subscribed to this bug | 03:57 |
jbailey | pitti: I could try, but in case I need to twiddle build-deps on something, I'd prefer to not half-start work in place and have to move it. | 03:57 |
rodarvus | jbailey, what # is it? | 03:57 |
jbailey | rodarvus: 54352 | 03:57 |
pitti | rodarvus, doko: ah, interesting reading on http://linuxfromscratch.org/pipermail/hlfs-dev/2006-June/003031.html | 03:59 |
rodarvus | jbailey, thanks, I'll have a look at it later today, hopefully | 03:59 |
jbailey | rodarvus: Thanks, it appears to lock the machine solid, so I'm not sure how to get a bug report out of it. | 03:59 |
jbailey | rodarvus: Any suggestions on how to debug this would be good - I'm sure we'll run up against this type of bug in support occasionally. | 04:00 |
rodarvus | this kind of stuff is hard to debug, really -> a good start is the output of lspci -vv, Xorg.log.0 (if it is created) and if possible, Xorg.log.0.old (which should be from the previous version of the driver) | 04:04 |
rodarvus | knowing what board exactly is installed is helpful to track related changes in upstream git repository, and also to contact upstream authors | 04:04 |
jbailey | I'll see what I can drag up from the log files, but becaus eof the version skew on the ATI driver, I might not be able to get it. | 04:05 |
rodarvus | indeed | 04:05 |
jbailey | I upgraded the rest of X a day or so ago, but -ati- hadn't gone in, so X failed to load before. | 04:05 |
rodarvus | jbailey, appreciated! | 04:05 |
jbailey | Thanks. It'll be tonight. I'll also probably roll my machine back to the old version of X so I have it running, so I might get it for you that way ;) | 04:05 |
rodarvus | :) | 04:08 |
rodarvus | jbailey, you can probably also get the machine into a usable state by using the 'vesa' driver | 04:08 |
rodarvus | (instead of returning all of the X libraries and drivers to the previous version | 04:09 |
jbailey | Hmm. For some reason I thoguht the R300s didn't have a working vesa mode. | 04:10 |
jbailey | Thanks for the reminder =) | 04:10 |
rodarvus | oh, its a R300 | 04:12 |
rodarvus | that might explain a few things :D | 04:12 |
jbailey | Certainly ;) | 04:12 |
jbailey | R300 on ppc64 is generally known to be.. special. | 04:13 |
jbailey | But this is the first solid-hang on initialisation that I've seen with t. | 04:13 |
jbailey | I already have the hardware acceleration disabled, which usually solves most of the problems. | 04:13 |
rodarvus | hmm | 04:18 |
=== rodarvus takes notes | ||
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus] has joined #ubuntu-toolchain |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!