[12:53] aftermppm [12:53] afternoon, even [12:53] jbailey: lamont: bunch 'o files copied long ago from the kernel tree -- i hated doing that but there wasn't a good alternative at the time [12:54] so I think that means there's a patch to palo in the future... === lamont mutters curses at doko's uploads [01:05] ? [01:06] lamont: you must be more specific, I can't remember all uploads anymore ;) [01:07] heh [01:07] hppa built a b0gus libgnomedb, which is not installable. [01:08] testing the 'force a rebuild' change to verify that it is a sufficient fix. [01:08] (it depends: libgda2-1 instead of -3...) [01:08] but that was a seb128 upload, not yours [01:09] it's from the "versioned build-deps are too much of an annoyance to bother with" camp. [01:10] yes, I'm from the "upload many some will get through" camp === lamont uploads libgnomedb [01:36] *grumble* [03:03] lamont: 'kay. You have a working palo you can use in the meantime? [03:03] jbailey: hoary's works. [03:04] so it blocks debootstrappable breezy, but then, so do gcc-4.0 et al. [03:04] debootstrap installs a bootloader? =( [03:05] hrm... no [03:05] nm [03:06] Ah, good. [03:06] So we get to worry about that when we're far enough along to think about d-i. [03:07] exactly [03:07] and switching it to build with gcc-3.3 is always a workaround. :-) [03:07] possibly even a working one [03:37] doko: g++-4.0 upgrade from -7ubuntu6 to -7ubuntu7 seems to have broken compilation of socketapi, at least :) my c++ skills aren't what they should be to fix it. [04:08] ajmitch: Pasting error message, good. [04:08] jbailey: error message requires some source as context [04:09] Really? sometimes it's obivous by the error message. [04:09] sctpassociation.h:429: error: expected `)' before '*' token [04:09] sctpassociation.h:439: error: ISO C++ forbids declaration of 'SCTPSocket' with no type [04:09] sctpassociation.h:439: error: expected ';' before '*' token [04:09] that requires a bit of context, i think :) [04:15] Can you feed the g++ through with gcc -E -dD and find the lines that fail and paste them? === ajmitch can give it a go.. === elmo [~james@83-216-141-215.jamest298.adsl.metronet.co.uk] has joined #ubuntu-toolchain [05:02] elmo; mwah. [05:05] dh_strip -pgcj-3.4 -plibgcj5-dev [05:05] doko: does that mean it's gonna build"? [05:06] lamont: That sounds good. What's different? [05:06] liberal use of 'killall -9 expect' every time the kernel dropped a signal. :=) === daniels stares at lamont. [05:06] mind you, that has the effect of killing more than just the parent that will never know it's child died... [05:07] daniels: stop staring. STFU [05:07] lamont: LOL [05:08] we just need to get doko to quit writing tests that stress the kerrnel bugs... [05:08] that or fix the kernel bug [05:09] lamont: My mother was reading one of my programming books when I was still living at home about the importance of killing your children when you were done with them. [05:09] lamont: She said she approved of my choice of reading material. [05:09] jbailey; reaping, you mean :) [05:09] desrt: I think this was a GUI programming book. [05:10] ah [05:10] i'm suprised schools haven't banned the learning of C/unix programming due to the obvious violent/suggestive undertones [05:12] dpkg-genchanges! [05:17] now if i could just get logwatch.sh to actually _exit_ by itself [05:17] Built successfully [05:17] Purging chroot-breezy/build/buildd/gcc-3.4-3.4.4 === lamont thinks there should be "" around that successfully. :-( [05:19] lamont : logwatch still doesn't exit on its own?... I meant to fix that bug ages ago. [05:20] infinity: there's an hppa issue with child reaping in the signal case... [05:21] that is, there's a signal bug.. it screws up a few things... [05:21] And fixing the kernel bug is too much to ask? :) [05:22] infinity: You have spare cycles, don't you? [05:23] jbailey : Personally, or hardware-wise? [05:23] I don't think /I/ have much for spare brain cycles, but I have some machines with spare cycles. [05:23] infinity: persnoally. =) [05:27] infinity: it's on my list... [05:32] to bed soonish [05:32] lamont: And you've got glibc in there now as well, right? [05:33] pool/main/g/glibc/libc6_2.3.5-1ubuntu3_hppa.deb [05:34] Cool. I might see if I can get generic function descriptors working next to fix those testcases, but I'll probably focus on breaking sparc. Fabio's given the okay for dropping classic sparc. === lamont cries for his sparc boxen [05:38] lamont: Cry in sadness? [05:38] Do you still need classic sparc supported? === lamont has an ss5 and an ss20, both classic. both turned off. [05:40] given that we don't currently even have a 32-bit kernel, it's not like losing glibc makes a big difference... [05:40] Do you have a real objection to stacking them with the i386 boxes? =) [05:40] Classic sparc was so slow, it drove me to work on m68k cause I craved a modern and speedy architecture. [05:53] jbailey: feh. I'll ebay 'em if they're totally dead. Otherwise they can be my native debian test boxes... :-) [05:53] g'night [05:57] morning [05:57] night lamont [06:11] fabbione: We were just talkimg about Sparc. =) [06:12] Anyhow, you sohwing up means bedtime for me. =) [06:12] g'n! [06:12] ehhe [06:12] good night jb :) [06:18] That's a clever avoidance technique. [06:18] "I, uhh, shouldn't stay awake past when you get up... Yeah, that's it!" [07:39] yay [07:39] gcc-4.0 did build fine too :) [07:39] doko, jbailey: when can i expect a ppc64 toolchain available? [07:40] possibly updated and installed in a breezy-ppc64 chroot? [09:26] good morning === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain [10:40] daniels: with which upload will the headers move to /usr/include/X11? [10:52] doko: as I've explained before, as each module moves out [10:52] there will be no one upload [10:58] so when will xinerama be available in /usr/include/X11 [11:21] doko: when I modularise libxinerama [11:22] daniels: looks like I'm pestering? ;-) just want to know, when it will be in the archives [11:24] dude, I really don't know [11:24] i'll let you know when it is, though === chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain [12:04] <\sh> doko: thx for the helping hand in uploading :) [12:10] <\sh> but where is licoin20c102 in the coin2 package? [12:11] ermm [12:11] you stole that for me :P [12:13] <\sh> chmj: what? ;) [12:13] <\sh> there was no name on the list ;) and there is no libcoin20c102 in the debian/control :( [12:14] er ... libcoin20 is in coin, libcoin40 is in coin2 [12:17] <\sh> why is doko wrinting something like this in coin2? [12:18] <\sh> anyway..enough work todo [12:20] libcoin40 replaces libcoin20 ;-) [12:22] <\sh> then can be...but then I don't understand his remark: http://bugzilla.ubuntu.com/show_bug.cgi?id=11007 [12:22] <\sh> s/then/that/ [12:28] doko, ping ? [12:30] hmm, I'll have a look, was late yesterday ;) [12:30] <\sh> doko: but u rock like a hurricane :) [12:31] heh [12:32] <\sh> Extra for doko, I will disturb our holy free day with === \sh is playing "Rock you like a Hurricane" by Scorpions on The Essential [01:19] fabbione: Are you in a rush for ppc64 stuff? [01:20] jbailey: we need to get ppc64 kernels out as soon as we can.. if we can [01:20] the changes are quite a lot to test [01:20] so it's not exactly an easy path to follow [01:22] fabbione: Ah, okay. I know that svenl wants them fairly soon too. I'll do another round on gcc-3.4 today then. Last I left it, it was building the compiler fine, but not giving me the lib64gcc_s.so library. [01:23] ehehe [01:51] jbailey: not the package, or the library? [01:52] doko: Both, so I'm guessing I was overenthusiastic in disabling things. [02:00] doko: Rather than env variables and hacking rules.defs, it would be nice if the end of the file contained a "-include debian/rules.override" which allowed me to set the languages and such definitively if the file exists. [02:01] WITHOUT_LANG=ada,java dpkg-buildpackage works [02:01] That still causes libffi,fortran and g++ to be built. [02:02] For the initial tests I had been avoiding those. [02:02] I've also been using WITHOUT_CHECK until it builds all the pieces. === zul [~chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain [02:23] I can never remember if zul was they gatekeeper or the keymaster. [02:24] -y [02:24] gatekeeper [02:25] Cool. =) [02:26] Bah, forgot pascal in the languages to skip [02:26] heh...i never did pascal :) [02:26] jbailey: WITHOUT_LANG=ada,java,c++,objc,f77,treelang dpkg-buildpackage [02:27] Ah, didn't you? It think it was my 3rd language. basic then z80 assembler first. [02:27] it's f77, I'll add ffi [02:27] debuild -e WITHOUT_LANG=ada,java,c++,f77,treelang,pascal,objc -e WITHOUT_CHECK=y [02:27] is what I was about to use. === lamont ponders where pascal landed in his list [02:30] basic, 6502, z80, hp21mx asm, hpl (hp9825), spl (hp3000), hp3000 asm, cobol (gak), pascal, modcal, hppa asm, C, hp41 ucode [02:30] I think I didn't forget any before pascal. :-) [02:31] lamont: there's not much after pascal :p [02:32] doko: I was getting old at that point. :-) [02:32] basic, z80, pascal, i386 (*cRy*), telix scripting, C, javascript, c++, php, python, Java (including all the fluffy languages) [02:32] somewhere in there (around kobol timeframe) is DEAL (which looks like algol with fortran printing) [02:32] YOU MEAN IT'S ALL CAPS AND WHITESPACE SENSITIVE? =) === lamont skipped all the interpreted langs besides basic... [02:33] jbailey: I only learned it well enough to translate an app or 3 from DEAL to COBOL. :-( [02:33] lamont: Javascript is the only one of those that I haven't compiled to native code at some point. === lamont hated being a cobol whore. === lamont goes to play with fire at the power plant [02:33] really [02:33] lamont: Or to some sort of bytecode, I guess (for python) [02:34] telix's SALT language was terribly cool. Packet switched networks are lovely when you're still covered by the young offenders act. [02:37] basic pascal modula-2 C Opal Haskell Prolog Modula-3 Tcl Perl Eiffel Sather Python Lua, yes I'm supposed to do the C++ and Java stuff ... [02:39] ok, working around the xorg reorg, building OOo [02:39] jbailey : I used telemaet and TMscript, but SALT was fun too... [02:41] hmm, BASIC z80-asm x86-asm Pascal C Java ML Prolog arm-asm Perl C++ Python, I think [02:41] nice, finally someone for assigning the C++ bugs to ;-) [02:42] sod off :-) [02:42] What' Kamion said [02:42] (I can't pull it off why my accent) [02:42] I never used the C++ standard library much [02:42] Eww. You're one of *those* C++ coders. =) [02:43] we had our own standard library, when I was doing C++ seriously - when the project in question started, the C++ standard library was barely standard and certainly not portable [02:43] and it was so much more comprehensible than libstdc++, anyway. :) [02:44] I tried desperately to add Scheme to my list for almost a year before deciding that the pain just wasn't worth it. [02:44] lamont: please yould you trow all the gnome stuff at the buildd's again, once libenchant1c2 is in main? [02:46] yesterday I started a gcc build on my powerbook. [02:46] getting too hot, the computer turned off ... [02:50] Ithought powerbooks were supposed to have decent fans for that sort of thing. [03:00] doko: I have a full build log now and I don't see lib64gcc being built at all. Do I need more than --enable-languages=c passed to configure to get that? [03:15] biarch is turn on? [03:15] biarch is turned on? [03:16] and with_lib64gcc is set? [03:22] yes to both. I know biarch is set because the resulting compiler includes the ability to do -m64 [03:22] (It just can't find the missing lib64c_s) [03:23] the with_lib64gcc doesn't show up in the build log so it's harder to prove, but it's set in the same place that biarch is set. [03:24] and a find build -name libgcc* doesn't find anything 64bit like? [03:26] Oh, hmm, it's build/gcc/libgcc_s_64.so [03:26] I have been grepping the build log for lib64gcc [03:27] look at debian/rules.defs, if with_lib64gcc is defined [03:27] So it's there with no package created. Excellent. That gets back into the realm of things I can track. =) [03:27] ifeq ($(DEB_TARGET_GNU_CPU),powerpc) [03:27] biarch := yes [03:27] with_lib64gcc := yes [03:27] with_lib64cxx := yes [03:27] endif [03:28] I know it has to do doing that because of rules2: [03:28] ifeq ($(findstring powerpc-linux,$(DEB_TARGET_GNU_TYPE)),powerpc-linux) [03:28] ifeq ($(biarch),yes) [03:28] CONFARGS += --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 [03:28] Nothing else would be setting biarch. [03:29] found it [03:30] debian/rules.d/binary-libgcc.mk: I assume, if you don't want a normal libgcc, you neither want a 64bit libgcc. [03:30] well, you can argue about it ... [03:31] Right. Ideally this should be provided by gcc4. [03:31] The logic's usually right. [03:35] Mmm, I don't see that. I see if biarch, files_gcc += 4{gcc_lib_dir}/64/stuff. [03:36] Where is it taken away if you're not building a regular libgcc? [03:38] i think the meaning of "biarch" has just got a lil confusing to me [03:40] chmj: Heya Charles. [03:40] chmj: The context here is a compiler that can produce binaries for what it beleives is it's 32 bit and 64 bit incarnations. [03:40] Some of the biarch setups are really logical, like ppc and ppc64, sparc and sparc64. [03:41] Some of them are less obvious, like i386 and ia64, or i386 and amd64. [03:41] ohh yes [03:42] jbailey: with_libgcc is set to no in 3.4, move the 64bit test at the top out of the ifeq [03:43] DOH, binary-libgcc, not binary-gcc [03:43] You're in a maze of twisty passages, all alike. === jbailey has another sip of the bong water. [03:44] Lesse if -nc is my friend today. [03:45] It is, lovely. [03:46] Need to fix symlnks and such. [03:46] doko: How do you want the patch to the debian/ directly? [03:46] directory [03:46] Bah. [03:46] Time for a walk soon. [03:48] just email the diff [03:53] Cool, afk a couple minutes. [04:23] doko : Did you have a list of stuff you wanted thrown back at the buildds? [04:24] infinity, no not explicitely, I was working from breezy_probs [04:27] infinity: Are you so empowered now? [04:27] infinity: If you are, I swear we're dragging you onto some doko-jbailey friendly timezone. =) [04:28] infinity: prove your power, throw back sound-juicer! ;-) [04:34] Alright, kicked. [04:34] jbailey : Yes, I am. [04:34] jbailey : Though, I only have access to 4 of 12 buildds currently. One of each arch. Not sure what the reasoning is for that one. :) [04:37] well, they know that 3 out of 4 won't get borked ;) [04:38] Or that 1 out of 4 won't. ;) === infinity sticks his tongue out at lamont. [04:38] Anyhow, I have full w-b access, which is the more important thing, so I can mangle all your give-back requests and such. [04:39] My god, the power. I wish I had w-b rights on all the Debian arches. [04:39] Doing a give-back on all arches at once felt kinda... Tingly. [04:40] I think I might still have it on sparc in Debian. =) [04:40] Of course, I'm not sure kicking it back was such a fantastic idea.. [04:41] infinity: congratulation :) [04:41] infinity: It's not m68k, these things can cope with the odd mistaken give-back [04:44] jbailey : Thpt. :) [04:44] infinity: So does this mean you'll be my build bitch for biarch ppc64? Svenl's just confirmed it works for me. =) [04:47] svenl confirmed that it works.. for.. you? [04:48] I don't have a ppc64 kernel. [04:48] There's something very odd about that sentence. [04:48] He ran my hello world binary. [04:48] Right, well, none of our ppc buildds have ppc64 kernels either. THat'll need to change if we're meant to be doing ppc64 stuff on them, I guess. [04:48] No. [04:49] Notice that I couldn't test the ppc64 binary but produced one. =) [04:49] Sure, but anything with a test suite would flop. [04:49] Bah, testsuites. [04:49] Yeah. For pussies, I know. [04:49] If it's not in the bootstrap path, who needs a testsuite? =) [04:49] [04:50] Oh wait. [04:50] That wasn't a very good sensor, was it? [04:50] I assume you meant censor. [04:50] Cause sensored brings odd images to mind. [04:50] Right. =) [04:50] Of you feeling... pussies.. and testsuites. [04:51] I can only imagine your wife doesn't like where this is going. [04:51] Anytime now I suspect this should shift from a work channel to a /query window. =) [04:51] jbailey: would you mind, if I add some more patches to 3.4? [04:51] Nah, query schmery, we can just stop talking about it. [04:51] doko: Not at all are you going to make fabio scream^W^W^Wupload it, or send me the patches? [04:51] infinity: i run his ppc64 binaries on the augsbourrg 8-way power5 in pure-64 mode box. [04:52] fabbione: what is the status of the ubuntu kernel on ppc64 ? [04:52] jbailey : Anyhow, what do you need me for for biarch stuff, when you can build on your own? [04:52] jbailey: send me the diff, then I'll send you my diff back [04:52] fabbione: did you already work on it, want me to have a look or whatever ? [04:52] ehh, I mean, the merged one ... [04:53] doko: Sounds lovely. I'm just pushing the gcc debs to people.ubuntu.com right now so that I have them as a backup [04:56] svenl: without a toolchain i can't do it. [04:56] svenl: when i tought we had one, the chroot was broken.. so i couldn't install all the kernel build-deps [04:56] that's why i pinged jb and doko this morning again [04:57] but clearly.. if you want to do something and help, you are welcome [04:57] fabbione: Well, you have a toolchain sitting in my p.u.c directory now if you want it. [04:57] jbailey: can we get installed in a breezy chroot on davis? [04:57] if so i can start to work on them from monday [04:57] tomorrow is userland day [04:58] and i really plan NOT to touch the kernel [04:58] With any luck they'll be in the archive tomorrow. [04:58] ok than i won't bother to rush [04:58] i will wait them as naturale upgrade [04:59] jbailey: but i will need to know the versions of packages i need to b-d at least [04:59] fabbione: Yup. Should hopefully be really obvious by then. [04:59] jbailey: ehehe [05:00] doko : Any others you want to give the boot? Or should I just pull a lamont and give-back everything from main? [05:05] infinity, no, currently not, have to fix things first ... [05:06] doko: Umm. Is debian/README.Debian autogenerated? =) [05:08] doko : Oh. In that case, I gave back a few things, but I won't touch any more. I need to get some sleep, and I suspect lamont may be back before I am. [05:08] But I'm not really sure who'll be here first. :) [05:09] infinity: We're moving you to an island in the mid-atlantic. =) [05:12] jbailey: yes [05:13] doko: Oh good. =) [05:21] jbailey : Uhm. I don't think I like that idea so much... [05:21] jbailey : If you manage to get Mark to override my protests, at least score me a massive raise along with it. [05:21] infinity: Nah, salaries are market rate, aren't they? How much can a pineapple cost if you're the only one on the island? [05:23] Right, so I hate you now. [05:23] doko: http://people.ubuntu.com/~jbailey/biarchppc.diff [05:23] infinity: You hated me before. It was a leap of faith to share a room with you at debconf. [05:23] Trusting that you were still Canadian enough to not kill me in my sleep. [05:24] fabbione: ok, so i will be the first one to build ppc64 kernels. [05:24] Also, it's 1:23am, and I have a girlfriend who wants me either cuddling or dead, and I'd rather the former. [05:24] But I had an Inuit carving handy, just in case. [05:24] fabbione: the baz infocation you gave me earlier is a good starting point to do that, right ? [05:26] svenl: it's the same point i will start from (more or less) [05:26] svenl: more or less is determined by other guys committing to it for other stuff [05:26] jbailey, btw, debian/control is generated as well ... [05:26] doko: In the patch, you'll see that I removed the leading /'s from the dh_link line. It's probably not necessary - it was the trailing \'s that turned out to be the problem. === chmj [~d3vic3@dumbledore.hbd.com] has left #ubuntu-toolchain ["Leaving"] [05:27] doko: Yes. I didn't remove generated files, I was going through and verifying them... And scared to see that a README file had changed when I didn't expect it to. [05:27] fabbione: ok. [05:28] svenl: i suggest you to learn how to branch and export your local archive [05:28] svenl: so at a later stage i can merge directly from your archive [05:28] other than starting a diff -u mess [05:28] fabbione: but consecutive to the discussion we held about iseries/pseries/pseries-power4 and co, you didn't go ahead and implement that somewhare ? [05:29] somewhere even. [05:29] svenl: ENOTIME [05:29] svenl: changing naming is the last of the problems :) [05:29] fabbione: hehe. [05:29] there is more that needs to be done :) [05:29] fabbione: do you have a summary of the decisions we took back then though ? [05:30] svenl: powerpc, powerpc-smp, pseries-smp, pseries-power4, [05:30] pseries-power4-smp, iseries-smp [05:31] that's what we agreed before we decided to kill power4 [05:31] ok. [05:31] so nothing more than what we discussed. [05:31] so remove power4 from there [05:31] nope [05:31] i don't talk alone.. usually [05:34] fabbione: :) [05:34] fabbione: i will build stuff, will probably take me upto this WE to get kernels done and somewhat tested, i will come back to you then to see if it is worth integrating or need further work or whatever. [05:34] I talk to myself, my wife finds it funny. [05:35] Apparently since UDU I now swear at my computer in an English accent [05:35] (thanks elmo, keybuk, and kamion) =) [05:35] jbailey: i do it, but only when i am extremely tired. it helps me focusing [05:35] my wife thinks it's time to take out of the cave when i do that [05:37] Oh, next step is to bring the biarch stuff to 4.0 i guess. [05:38] jbailey: how's the libc6-dev-powerpc package called? [05:39] libc6-ppc64 and libc6-dev-ppc64 [05:39] jbailey: would libc6-ppc64-dev not make more sense ? [05:39] svenl: I'd have thought so, but this matches how it was done for the other archs. [05:40] bah. [05:41] luther@trick:~$ file ./sventest [05:41] ./sventest: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for GNU/Linux 2.6.0, statically linked, not stripped [05:41] luther@trick:~$ ./sventest [05:41] Hello 64bit World! [05:41] Ok, built fine for me, now is kernel building time. === svenl wonders if i should try to setup a chroot on the augsbourg 8-way power5 box. [05:42] doko, jbailey: thanks for the great job you did on this. [06:14] jbailey, infinity, lamont: gcc-3.4 on chinstrap:~doko/uploads/ [06:16] doko: What magic does this one have? [06:16] like, is the ppc64 stuff included? [06:17] lamont, infinity: please kick back gnome-panel on amd64 [06:17] jbailey: yes [06:19] doko: Cool, thanks. [06:20] but the i386-biarch wasn't in the patch ;-P [06:22] Bah, the build failed after stage2. =( /me checks to see what it died on. [06:23] doko: Can I post this build log somewhere to get your help looking at it? [06:23] yup [06:25] http://people.ubuntu.com/~jbailey/gcc-3.4_3.4.4-0ubuntu3_powerpc.build [06:26] yes, trying to run a 64bit test program on a 32bit kernel [06:26] Right, but why? [06:26] And after stage3... [06:26] At that point everythin ought to be built. [06:31] yes, it's a "sanity" check, before the runtime libs are built [06:33] is the i386-biarch patch applied? [06:33] stamps doesn't have anything that matches *biarch* [06:33] But I see it in the root directory. [06:37] yes, it's disabled, because it didn't work with amd64-libs-dev [06:40] so you have to re-enable biarch in debian/rules.defs and rebuild. [06:40] Sorry - this is still ppc/ppc64 I'm working on. [06:41] I was doing the full build rather than the just C one that I had been doing before. [06:43] hmm [06:53] please could you put your current glib packages online? [06:54] http://people.ubuntu.com/~jbailey/glibc/ [06:54] http://people.ubuntu.com/~jbailey/gcc/ [06:54] for the C-only, no-testsuite-run compiler. [07:26] jbailey: it failed again at the same place : [07:27] Adding multilib support to Makefile in ../../../src/libstdc++-v3 [07:27] multidirs=64 nof [07:27] with_multisubdir= [07:27] Running configure in multilib subdirs 64 nof [07:27] pwd: /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/powerpc-linux/libstdc++-v3 [07:27] Running configure in multilib subdir 64 [07:27] pwd: /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/powerpc-linux [07:27] mkdir 64 [07:27] ... [07:27] checking for powerpc-linux-gcc... /home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/gcc/xgcc -B/home/sven/ubuntu/biarch/gcc/gcc-3.4-3.4.4.orig/build/gcc/ -B/usr/powerpc-linux/bin/ -B/usr/powerpc-linux/lib/ -isystem /usr/powerpc-linux/include -isystem /usr/powerpc-linux/sys-include -m64 -fPIC -mstrict-align [07:27] checking for C compiler default output file name... a.out [07:27] checking whether the C compiler works... configure: error: cannot run C compiled programs. [07:27] doko: do you have any idea ? === jbailey runs off to meet Angie. [07:30] svenl: no [07:37] jbailey: :) [07:37] doko: any hint on where i can check in the Makefiles/whatever what it is doing here ? === svenl guesses it is trying to run the 64bit binaries built previously with the ppc64 compiler. [07:39] svenl: yes [07:39] well, where do i check the code doing that ? [07:40] in src/libstdc++-v3 [07:40] ? [07:41] in the configure script there i guess. Which do i investigate ? configure.ac or .host ? [07:43] maybe we should set cross compiling in src/libstdc++-v3/configure, or add a special case for biarch if on ppc32 arch ? [07:44] code is : [07:44] # Check the compiler produces executables we can run. If not, either [07:44] # the compiler is broken, or we cross compile. [07:44] echo "$as_me:$LINENO: checking whether the C compiler works" >&5 [07:44] echo $ECHO_N "checking whether the C compiler works... $ECHO_C" >&6 [07:44] # FIXME: These cross compiler hacks should be removed for Autoconf 3.0 [07:44] # If not cross compiling, check that we can run a simple program. [07:44] if test "$cross_compiling" != yes; then [07:44] if { ac_try='./$ac_file' [07:44] { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 [07:44] (eval $ac_try) 2>&5 [07:44] ac_status=$? [07:44] echo "$as_me:$LINENO: \$? = $ac_status" >&5 [07:44] (exit $ac_status); }; }; then [07:44] cross_compiling=no [07:44] else [07:44] if test "$cross_compiling" = maybe; then [07:44]