[12:09] <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:10] <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:11] <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:12] <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:15] <pitti> 'k, I modified debian/rules, running now
[12:37] <doko> pitti: powerpc?
[12:39] <pitti> no, amd64
[12:40] <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:41] <pitti> oh, they are there (the b-deps) on davis, how convenient
[12:41] <pitti> doko: ok, then your build was way faster
[12:42] <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:43] <pitti> ok, ppc test build with 'CC=gcc-4.1 -fno-stack-protector' is running
[12:44] <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:55] <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:56] <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
=== Keybuk [n=scott@quest.netsplit.com]  has joined #ubuntu-toolchain
[01:02] <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:03] <doko> i386 works fine for me as well ...
[01:04] <pitti> hmm
[01:06] <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:08] <doko> no, I asked for dist-upgrades this or last week
[01:08] <pitti> hm, indeed it's the last version
[01:16] <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.
[02:50] <doko> jbailey: both i386 and amd64 build with -fno-stack-protector. cannot check the powerpc build.
[02:51] <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:54] <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:56] <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:57] <jbailey> Cool, thanks.
=== 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
[03:24] <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:25] <rodarvus> can this bug be somehow related to the stack protection changes which happened recently?
=== pitti [n=pitti@ubuntu/member/pitti]  has joined #ubuntu-toolchain
[03:42] <pitti> hi
[03:43] <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:44] <rodarvus> (there)
[03:45] <doko> rodarvus: now you can try again ... ;-)
[03:45] <pitti> yep, got it
[03:46] <rodarvus> doko, thanks :)
=== freeflying [n=freeflyi@ubuntu/member/freeflying]  has joined #ubuntu-toolchain
=== freeflying [n=freeflyi@ubuntu/member/freeflying]  has left #ubuntu-toolchain ["Konversation] 
[03:49] <pitti> rodarvus: hm, I have no clue where __stack_chk_fail_local() is defined
=== jbailey [n=jbailey@209.217.74.66]  has joined #ubuntu-toolchain
[03:49] <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:50] <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:51] <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:52] <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:53] <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:54] <rodarvus> pitti -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/
[03:55] <pitti> rodarvus: ok, I added it to https://wiki.ubuntu.com/GccSsp
[03:56] <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:57] <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:59] <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.
[04:00] <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:04] <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:05] <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:08] <rodarvus> :)
[04:08] <rodarvus> jbailey, you can probably also get the machine into a usable state by using the 'vesa' driver
[04:09] <rodarvus> (instead of returning all of the X libraries and drivers to the previous version
[04:10] <jbailey> Hmm.  For some reason I thoguht the R300s didn't have a working vesa mode.
[04:10] <jbailey> Thanks for the reminder =)
[04:12] <rodarvus> oh, its a R300
[04:12] <rodarvus> that might explain a few things :D
[04:12] <jbailey> Certainly ;)
[04:13] <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:18] <rodarvus> hmm
=== rodarvus takes notes
=== rodarvus [n=rodarvus@ubuntu/member/rodarvus]  has joined #ubuntu-toolchain