/srv/irclogs.ubuntu.com/2006/07/28/#ubuntu-toolchain.txt

pittihm, so it seems that glibc wants to build some parts of it without ssp12:09
dokojbailey: no, libssp0 isn't really used, I should not build it, if we build on a glibc-2.4 based system12:09
pittidoko: 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
pittidoko: 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 again12:11
dokopitti: yes, that should do it12:11
pittiok, worth a try in any case. I'll start a test build now, it should finish by the end of the meeting12:12
pitti'k, I modified debian/rules, running now12:15
dokopitti: powerpc?12:37
pittino, amd6412:39
pitti<doko> jbailey: amd64 and i386 builds fail as well12:40
pitti^ so testing on amd64 should be fine?12:40
pittimy laptop still runs dapper, and would take ages anyway12:40
pittiif I should test it on powerpc, I'll rather request the b-deps on davis12:40
dokopitti, jbailey: amd64 build using -fno-stack-protector succeeded12:40
pittioh, they are there (the b-deps) on davis, how convenient12:41
pittidoko: ok, then your build was way faster12:41
pittidoko: I start a ppc test build now if you want me to12:42
pittidoko: on my amd64, I changed CC, but changing {BUILD,HOST}_CFLAGS should work as well; what did you use?12:42
pittiok, ppc test build with 'CC=gcc-4.1 -fno-stack-protector' is running12:43
pittijbailey: indeed most of the files in glibc are *not* build with explicit -fstack-protector; only 48 of them12:44
pittiso maybe upstream saw the same problem and is only gradually enabling it, who knows12:44
pittihm, amd64 failed for me12:55
pittiwhen building the i386 version12:55
pittichecking for forced unwind support... no12:55
pitticonfigure: error: forced unwind support is required12:55
pittialso,12:56
pittichecking for -fstack-protector... no12:56
pitti^ for the i386 build12:56
pittithe amd64 build worked fine12:56
=== Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-toolchain
pittijbailey: hm, powerpc fails as well, but due to a completely unrelated issue01: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 here01:02
pittiand similar errors before that01:02
dokoi386 works fine for me as well ...01:03
pittihmm01:04
dokoI have a slightly newer compiler version, but I doubt that changes anything01:06
pitticertainly not wrt that double declaration01:06
pittimaybe the davis chroot has an older compiler version01:06
dokono, I asked for dist-upgrades this or last week01:08
pittihm, indeed it's the last version01:08
jbaileypitti: Right, that's a conflict in lkh tha tI need to work around, but that's easy enough.01:16
jbaileySorry about the lag, had a meeting.01:16
dokojbailey: both i386 and amd64 build with -fno-stack-protector. cannot check the powerpc build.02:50
dokoso it looks the outstanding issue is still long-double-128 ...02:51
jbaileyRight, ppc I can get to build base don what I've seen02:51
jbaileyI 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
jbaileyIs that not the case?02:54
dokojbailey: 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
jbaileyCool, 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
rodarvushi03:24
rodarvusI just received a bug report on xserver-xorg-input-synaptics -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/03:24
rodarvusdlopen: /usr/lib/xorg/modules/input/synaptics_drv.so: undefined symbol: __stack_chk_fail_local03:24
rodarvuscan 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
pittihi03:42
rodarvushi pitti03:43
rodarvusI 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
dokorodarvus: now you can try again ... ;-)03:45
pittiyep, got it03:45
rodarvusdoko, thanks :)03:46
=== freeflying [n=freeflyi@ubuntu/member/freeflying] has joined #ubuntu-toolchain
=== freeflying [n=freeflyi@ubuntu/member/freeflying] has left #ubuntu-toolchain ["Konversation]
pittirodarvus: hm, I have no clue where __stack_chk_fail_local() is defined03:49
=== jbailey [n=jbailey@209.217.74.66] has joined #ubuntu-toolchain
pittirodarvus: 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
rodarvussure, I'll do it03:50
rodarvusI'll also ask ogra to test it to me before uploading, just to make sure all is fine03:50
jbaileypitti: 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
jbaileyI'll try it a bit later.  I have a couple urgent things first.03:51
pittijbailey: yes, last one wins03:51
dokojbailey: you could check, if the __SSP__ macro is defined. but IIRC the last one wins03:51
jbaileyNice.  I'll try that for the glibc builds then.03:51
pittijbailey: yesterday's test build went well with 'CC=gcc-4.1 -fno-stack-protector'03:52
pittijbailey: apart from the duplicate symbol on powerpc that I pasted03:52
pittirodarvus: ok, I add it to the wiki page so that we have a reference03:52
pittirodarvus: is there an LP bug for it?03:52
jbaileyDuplicate symbol?03:53
jbaileyYou mean the elf_vrrg_reg thing?03:53
pittimight be, yes03:53
rodarvuspitti, yes bug 5435703:53
rodarvuspitti -> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-synaptics/+bug/54357/03:54
pittirodarvus: ok, I added it to https://wiki.ubuntu.com/GccSsp03:55
jbaileypitti: 'kay.  I'll run it...03:56
jbaileyor maybe I won't since my machine at home isn't on.03:56
jbaileyX bug that I filed earlier this morning.  *sigh*03:56
rodarvuspitti, nice, thanks!03:56
jbaileySo it'll be tonight when I get home to roll back X.03:56
pittijbailey: use a DC porter machine?03:56
rodarvusjbailey, I didn't saw this bug03:56
rodarvuslet me check03:56
rodarvusjbailey, apparently x-swat was not subscribed to this bug03:57
jbaileypitti: 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
rodarvusjbailey, what # is it?03:57
jbaileyrodarvus: 5435203:57
pittirodarvus, doko: ah, interesting reading on http://linuxfromscratch.org/pipermail/hlfs-dev/2006-June/003031.html03:59
rodarvusjbailey, thanks, I'll have a look at it later today, hopefully03:59
jbaileyrodarvus: Thanks, it appears to lock the machine solid, so I'm not sure how to get a bug report out of it.03:59
jbaileyrodarvus: 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
rodarvusthis 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
rodarvusknowing what board exactly is installed is helpful to track related changes in upstream git repository, and also to contact upstream authors04:04
jbaileyI'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
rodarvusindeed04:05
jbaileyI upgraded the rest of X a day or so ago, but -ati- hadn't gone in, so X failed to load before.04:05
rodarvusjbailey, appreciated!04:05
jbaileyThanks.  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
rodarvusjbailey, you can probably also get the machine into a usable state by using the 'vesa' driver04:08
rodarvus(instead of returning all of the X libraries and drivers to the previous version04:09
jbaileyHmm.  For some reason I thoguht the R300s didn't have a working vesa mode.04:10
jbaileyThanks for the reminder =)04:10
rodarvusoh, its a R30004:12
rodarvusthat might explain a few things :D04:12
jbaileyCertainly ;)04:12
jbaileyR300 on ppc64 is generally known to be.. special.04:13
jbaileyBut this is the first solid-hang on initialisation that I've seen with t.04:13
jbaileyI already have the hardware acceleration disabled, which usually solves most of the problems.04:13
rodarvushmm04: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!