[12:56] Ah, bugger, I see my thinko === jbailey grumbles. [12:57] Don't you love those moments where you realise that something shouldn't have worked the first time around? =) [12:58] doko: After this glibc upload, are you uploading the gcc with the fix for 260710? [01:06] jbailey: so you got bits for me yet? [01:06] lamont: No, I figured out why it won't build when it gets that far... [01:06] jbailey: -mcpu was 3.3, -mtune is 3.4/4.0 [01:06] oh. [01:25] lamont: eh... [01:25] lamont: hppa64. [01:26] lamont: Should we eventually be doing a biarch setup for that? === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain [01:32] jbailey: biarch on hppa doesn't work yet, it needs a cross - binutils packaged in binutils-hppa64 [01:33] Ah, okay. [01:33] glibc has this now: # hppa64 needs symlink /usr/hppa64-linux/include to /usr/include [01:34] 260710, yes it's better, the patch to fix -g1 was dropped from 3.4.4 [01:36] Eh? Dropped? [01:36] Do you plan to put it back in? [01:36] currently it is, but it shows some regressions in the testsuite [01:36] Ugh. =( [01:37] so, leave it out. [01:37] Upstream PR still has it listed as committed. [01:38] 'kay. I've forced -g0 right now for our main arch's + sparc. === doko [~doko___@dsl-082-082-188-241.arcor-ip.net] has joined #ubuntu-toolchain [02:21] I've fired off another round of this, it'll take a few hours to build, so I'll have to get it tomorrow. === ercxy [~ercxy@209-6-112-210.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has joined #ubuntu-toolchain [06:26] hi everybody [06:27] does anybody know how to increase stack size of a process ? === ogra [~ogra@p5089FB06.dip.t-dialin.net] has joined #ubuntu-toolchain === ercxy [~ercxy@209-6-112-210.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has left #ubuntu-toolchain ["Kopete] === svenl [~luther@AStrasbourg-251-1-58-57.w82-126.abo.wanadoo.fr] has joined #ubuntu-toolchain [09:27] doko: ? [09:46] fabbione: ? [09:46] doko: gcc-3.4 on sparc status: [09:47] i could reproduce the problem with a perfectly clean chroot [09:47] this time i kept the tree [09:47] well it seems like make all is not called in that direcotry before calling make install [09:47] otherwise it works perfectly [09:47] nice :( [09:47] the reason why it can't find libv3test.a is because it's not there [09:48] doko: i managed to rebuild the biarch glibc yesterdat. [09:48] fabbione: you build with sparc32 dpkg-buildpackage ... ? [09:49] doko: yes [09:49] that's automatic [09:50] doko: so, now i want to rebuild your biarch gcc packages, and you told me that the standard gcc packages will do. [09:50] doko: but i suppose i need to tweak some config options or something ? [09:51] yes, set biarch in debian/rules.defs. it's currently disabled. [09:52] doko: that's the only thing ? [09:52] doko: i am going to binNMU gcc-3.4 for sparc so that i can have the full toolchain but i would really love you to get it fixed properly, since this bug is a regression introduced recently [09:52] ah ok [09:52] ops [09:53] doko: i can just apt-get source gcc-3.4 modify it, and build it, and this will trigger the cannot-build-on-ppc32 bug, right ? [09:53] does jbailey still build using -g1? [09:54] doko: that was for me ? === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain [09:59] svenl: yes [09:59] doko: any hint on it ? [09:59] doko: or will you help me hunt it down or something ? [10:01] svenl: sorry, currently not the time, trying to have something for sparc when we start the transition [10:02] doko. Ok. [10:02] doko: not even a summary of what you have found out so far about this ? [10:03] doko: and i guess i will hit the problem sometime tomorrow only. [10:04] svenl: what do you mean? as it looks, you cannot build glibc with -g1 due to PR16676 [10:05] huh ? [10:05] doko: i built glibc, so i guess it is not the issue. [10:05] doko: about gcc. [10:10] doko: BTW, any idea of what will happen if i install these biarch glibc and gcc on a debian system ? [10:12] hmm, haven't tried yet. maybe install l-k-h as well? [10:12] yep. [10:13] but the glibc will be backward binary compatible, even if we enabled NPTL and biarch, right ? [10:29] doko, what is XXX_powerpc_XXX ? [10:29] doko: and should i also set with_lib64gcc and with_lib64cxx ? [10:31] svenl, that's the switch which needs to be enabled. [10:32] oh. [10:32] doko: so i should just remove the XXX stuff ? [10:32] yes [10:33] doko: and how will this handle the guys doing true-ppc64 and having a ppc64 or powerpc64 arch ? [10:33] the architecture is called powerpc64, not powerpc [10:33] doko: but the current package doesn't make provision for it, right ? [10:34] or you should change the XXX by powerpc64 or something ? [10:34] Anyway, this is not my problem ATM. [10:34] ask aj ... I think he did it prepare for 4.0 only [10:36] we will see once this happens. === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain [10:41] Damn. [10:42] lot of build depends to load, and apt-get is not happy with the gcc packages i have installed :/ [10:42] doko: do i need a biarch gcc to build the biarch gcc, or will just the biarch glibc do ? [10:44] biarch glibc is enough [10:45] ok, so i can install the standard gcc over the one i used to build glibc in the first place. [10:45] should work [10:47] i will tell you if it does not. [10:47] doko: so, is it better to start with gcc-3.4 or gcc-4.0 ? [10:48] according to jbailey, gcc-4.0 doesn't work to build glibc. [10:49] well. [10:49] let's start with gcc-3.4 for now then. [10:49] doko: am i supposed to rebuild glibc with this new gcc once i have it ? [10:50] doko: and how did you manage that ? Did you first build a biarch gcc bi hand for jbailey to use, or did he build one from upstream locally to build the first glibc ? [10:50] jbailey meant, that wouldn't be possible [10:50] doko: with 4.0 ? === Seveas [~seveas@dyn127.roaming.few.vu.nl] has joined #ubuntu-toolchain [10:50] doko: but ok with the biarch 3.4 i am building. [10:53] svenl: yes [10:53] doko: you didn't reply to my question about the way you originally built it :) [10:57] ARG. [10:58] it seems it didn't fix the linux-kernel-headers bad dependency :/ [11:10] hand fixed that. [11:11] ok, gcc-3.4 build started. === Seveas [~seveas@dyn127.roaming.few.vu.nl] has joined #ubuntu-toolchain [01:34] doko: at what time do you plan to start the transition on monday? [01:35] evening, when lamont and elmo are awake [01:36] doko: ok thanks [01:36] i am going to crontab the sparc buildd to stop at 2pm our local time [01:36] please do not start before that ok? [01:36] i should be already back at that time [01:37] fabbione: ok [01:37] but i can't be 100% sure [01:37] 0 14 * * Mon touch $HOME/EXIT-DAEMON-PLEASE [01:37] there [01:37] doko: if there are big issues, please tell lamont to stop it. he has access to the buildd [01:38] i should be already home by that time.. but you may never know :) [02:23] <\sh> mmm.. [02:31] <\sh> do i need to rename kdelibs4? === Seveas [~seveas@ksl403-uva-131.wireless.uva.nl] has joined #ubuntu-toolchain === rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain [04:25] Mmm, it kind of failed. stopped building and lot of gcc tests marked as FAIL. [04:25] doko: is this supposed to happen ? [04:26] doko: or more to the point, is this a symptom of the ppc64-kernel failure, or something else ? [04:29] svenl: which tests fail? [04:29] doko: i don't see any other obvious error message in the log. [04:29] doko: all of them [04:29] doko: which is why i think that something else went wrong. [04:31] look at the build logs to see why they fail [04:32] doko: where can i find it ? [04:33] i get stuff like : [04:33] Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. [04:33] Using /home/sven/ubuntu/gcc-3.4/gcc-3.4-3.4.3ds2/src/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. [04:33] find -name '*.log' [04:33] Running /home/sven/ubuntu/gcc-3.4/gcc-3.4-3.4.3ds2/src/gcc/testsuite/gcc.c-torture/compile/compile.exp ... [04:33] FAIL: gcc.c-torture/compile/20000105-1.c -O0 (test for excess errors) [04:33] FAIL: gcc.c-torture/compile/20000105-1.c -O1 (test for excess errors) [04:33] FAIL: gcc.c-torture/compile/20000105-1.c -O2 (test for excess errors) [04:34] output is : [04:34] spawn failed [04:34] Mmm. [04:34] better mount /proc [04:34] and /dev/pts [04:35] oh well. [04:35] Can i restart the build from where it left ? [04:36] nope, proc was mounted, but not /dev/pts. [04:37] mmm, how do i mount /dev/pts. ... [04:37] Mmm. [04:37] will installing that glibc in my real system break it horribly ? [04:39] Oh hell, let's try. [04:39] debian/rules check should work [04:39] doko: does running the build as root could have affected it ? [04:40] don't think so, although I work with fakeroot only [04:40] i am inside a chroot as root, /proc is mounted, but not /dev/pts. [04:41] so mount it and re-run [04:42] doko: how do i mount /dev/pts ? [04:43] proc /org/chroots/breezy/proc proc defaults,auto 0 0 [04:43] no, proc is ok, i know about it, /dev/pts is the one. [04:43] devpts /data/chroot/breezy32/dev/pts devpts defaults,auto 0 0 [04:43] ok. [04:44] mount: special device ptsdev does not exist [04:44] no fun :/ [04:46] err, the message was [04:46] mount: special device devpts does not exist [04:46] strange, [04:48] oh, well, need to go. [05:49] oh, well, no way to build gcc without moving to breezy will try again later on. === jbailey [~jbailey@dhcp802-2-37.dsl.ucc-net.ca] has joined #ubuntu-toolchain [06:24] lamont: hAround? [07:08] jbailey: am now [07:09] lamont: Cool, got source for you. [07:09] Just have one last dependancy to sort out. [07:09] doko: There? [07:09] lib64gcc1 depends on amd64-libs (>= 0.1) [07:09] amd64-libs is to be removed. [07:10] What do you want done about that? [07:10] I'm now conflicting with amd64-libs as we'd talked about. [07:11] lamont: The chroot basically needs to be: Current Breezy, add amd64-libs amd64-libs-dev from breezy, add: [07:11] cpp-3.4_3.4.3-13_i386.deb lib64gcc1_3.4.3-13_i386.deb [07:11] gcc-3.4-base_3.4.3-13_i386.deb libgcc1_3.4.3-13_i386.deb [07:11] gcc-3.4_3.4.3-13_i386.deb [07:11] from Debian [07:12] no [07:15] jbailey: away for the evening [07:15] features' might be clobbered by `longjmp' or `vfork' [07:15] {standard input}: Assembler messages: [07:15] {standard input}:59358: Error: Unrecognized opcode: `vand' [07:15] make[3] : *** [libkdefx_la.all_cpp.lo] Error 1 [07:15] /build/buildd/kdelibs-3.4.0/kdefx/kcpuinfo.cpp:75: warning: variable `int [07:16] that last line should be first [07:16] bad gcc [07:33] jbailey: hi. [07:33] svenl: hi. [07:33] jbailey: it is not possible to build stuff from inside hoary :/ [07:34] svenl: 'stuff'? [07:34] jbailey: gcc-3.4 [07:34] Errr. [07:34] Usually one of the last steps to a release is that we rebuild the archive to make sure there aren't FTBFSs [07:34] jbailey: at least not the biarch version from doko. [07:34] jbailey: the blocker is doxygen. [07:35] and doxygen depends on libgcc >= 1:4.0-2 [07:35] which is a breezy gcc-4.0 package i think. [07:35] and which overwrote my biarch libgcc. [07:36] so i am moving my box to breezy. [07:36] Breezy won't be a great improvement for you. [07:37] well, i will be able to install the build-depends of gcc-3.4 [07:37] I've started another build of a biarch glibc on ppc, I'll just post it for you. [07:37] but then, i wonder if the libgcc1 4.0.0-7ubuntu1 is compatible with the libgcc1ppc64 or whatever i just built. [07:38] the lib gcc1's should be completely unrelated to one another. [07:38] and the -dev ppc64 package of glibc depends on libgcc64. [07:38] ah. [07:38] It's only important when you're looking at optimsed libs for the same architecture. [07:38] There's pretty much no commonality otherwise, to the point where they use completely separate linkers and search paths. [07:39] jbailey: ok. [07:39] jbailey: BTW, what does this one glibc mean for userland libs ? [07:39] one glibc? [07:39] the biarch one i built ? [07:39] this one [07:39] Right, but it should really be two glibcs. [07:39] They just happen to coninstall. [07:40] Ok. [07:40] well, this way of doing things :) [07:40] co-install, rather. [07:40] It doesn't affect existing libs in any way. They will link against /lib/ld.so.1 (or whatever PT_INTERP is on ppc, I don't remember). [07:40] Any libs built for ppc64 will link against /lib64/ld.so.1 [07:41] So there's truly no relationship between them. That ld.so should be wired to look in different search paths and whatnot. [07:41] ok. [07:41] what does this mean for 64bit libs ? [07:41] they go in /lib64 and /usr/lib64 ? [07:41] Yes. [07:41] In practice very few of them get built. [07:42] Usually a few minor things like ncurses, zlib and such. [07:42] Whatever the bare minimum we need for an LSB system, basically. [07:44] I think we need ncurses, which is a build dependency of the 64bit procutils. [07:45] See two lines up. =) [07:49] ) [07:49] only comenting on why ncurses is needed, which is not really an important lib to 64bit-is. [07:49] alternatively, we can build a static procutils-64. [07:56] Well, we'd still need the library. [07:57] jbailey: this would be in the case of just ppc64 kernels. [07:59] jbailey: Now, if i want to upgrade my debian/sid system to use the new NPTL and biarch enhanced glibc, will this break my system ? [07:59] Obviously i will not be able to use it anymore to build debian packages, but that is another issue. [08:07] svenl: The best I can say is that it shouldn't. [08:07] I've been running the nptl-based stuff for a while with no issues. [08:07] But that was all on Hoary, etc. [09:09] <\sh> anyone awake? [09:33] \sh: Just got back, sup? [09:51] <\sh> jbailey: my question is already answered. [09:51] <\sh> jbailey: kdelibs4 has to be renamed === doko [~doko___@dsl-084-059-042-243.arcor-ip.net] has joined #ubuntu-toolchain [10:31] svenl: l? [10:32] svenl: I have the glibc-ppc64 bits if you want.