=== rtcm [~jman@217.129.142.72] has joined #ubuntu-toolchain | ||
=== doko_ [~doko___@dsl-082-082-194-086.arcor-ip.net] has joined #ubuntu-toolchain | ||
fabbione | morning | 06:18 |
---|---|---|
jbailey | Heya Fabio | 07:04 |
fabbione | hey Jeff | 07:29 |
fabbione | scp makediff rookery.warthogs.hbd.com:public_html/rhcluster-make.diff | 07:36 |
fabbione | makediff 100% 52KB 51.7KB/s 00:00 | 07:36 |
fabbione | Killed by signal 1. | 07:36 |
fabbione | jbailey: are you sure the latest crack is working properly? | 07:36 |
fabbione | i am getting a lot of sig 1 | 07:36 |
fabbione | or probably it's just ssh | 07:37 |
fabbione | yeah | 07:37 |
fabbione | indeed | 07:37 |
jbailey | Which crack? | 07:37 |
jbailey | The glibc? | 07:37 |
fabbione | i will bug Kamion | 07:37 |
fabbione | yeah | 07:37 |
fabbione | well i dist-upgraded yesterday | 07:38 |
fabbione | so probably it's ssh | 07:38 |
jbailey | Which arch? | 07:38 |
jbailey | ppc was the only one that got changes, and it just grew ppc64 bits. | 07:38 |
jbailey | The biarch configs aren't really associated with one another, so there should be 0 effect. | 07:38 |
fabbione | i386 | 07:38 |
jbailey | Hmm, I don't have a current breezy i386 system. | 07:39 |
fabbione | <fabbione> i will bug Kamion | 07:39 |
fabbione | i think it's only ssh | 07:39 |
fabbione | they looked more apps | 07:39 |
jbailey | Right, but since I'm here I'm just trying to think my way through whether it's possibly my fault. =) | 07:39 |
fabbione | but i realized i was only using a combination of apps with ssh backend :) | 07:39 |
fabbione | so with the ppc64.. | 07:40 |
fabbione | what versions and what b-d do i need to add? | 07:40 |
fabbione | for example: | 07:40 |
fabbione | Build-Depends: debhelper (>= 4.2.28), gcc-3.4, libxml2-dev, libncurses5-dev, libc6-dev-sparc64 [sparc] , libc6-dev-s390x [s390] | 07:40 |
fabbione | do i need to add libc6-dev-powerpc64 ? | 07:40 |
jbailey | libc6-dev-ppc64 | 07:40 |
fabbione | or something along that line? | 07:40 |
fabbione | ok | 07:40 |
jbailey | Whatever the current gcc-3.4 is for a versioned dep on that. | 07:41 |
jbailey | 3.4.4-0ubuntu4 | 07:41 |
fabbione | Version: 3.4.4-0ubuntu4 | 07:41 |
fabbione | rocking | 07:41 |
fabbione | # ifneq (,$(findstring $(DEB_HOST_ARCH), s390 sparc powerpc)) | 07:42 |
fabbione | :) | 07:42 |
fabbione | anyway the biarch build of rhcluster is disabled | 07:42 |
fabbione | because of the linking issue | 07:42 |
jbailey | *lol* | 07:42 |
jbailey | Just easiest for now? | 07:42 |
fabbione | i couldn't figure out why it fails | 07:42 |
fabbione | jbailey: as soon as i have the package in archive, we can work on it officially | 07:42 |
fabbione | since there will be ppc binaries :P | 07:43 |
jbailey | Right. | 07:43 |
fabbione | or since we should fix it for ppc64... we perhaps can do it before hand | 07:43 |
fabbione | using sparc for testing... | 07:43 |
fabbione | both ways work for me | 07:43 |
jbailey | Well, it's incentive for you to make me appc64 kernel. ;) | 07:43 |
fabbione | given that the 64bit is purely cosmetic | 07:43 |
jbailey | I tried to install svenl's and got a strange error when unpacking. | 07:43 |
jbailey | mmap error of some sort. | 07:44 |
jbailey | I haven't investigated it at all. | 07:44 |
fabbione | jbailey: i will start working on ppc64 kernels tomorrow | 07:44 |
fabbione | right now i need to do more userland stuff | 07:44 |
fabbione | since the rhcluster package has some implications | 07:44 |
fabbione | like providing b-d for main | 07:44 |
jbailey | Ah, what's today in userlanf? | 07:44 |
fabbione | still rhcluster | 07:44 |
fabbione | i need to split the package and start looking at init scripts | 07:45 |
fabbione | i need to change branch in the kernel patches to match userland | 07:45 |
fabbione | and verify the binary compatibility of my libs with the one in debian | 07:45 |
fabbione | given that the source come from 2 different upstream branches | 07:45 |
fabbione | and that the debian packages are pretty old | 07:45 |
fabbione | since upstream is messy, i might need to do a soname transition | 07:46 |
fabbione | that would probably be the safest thing to do anyway | 07:46 |
fabbione | (and it requires only one or two packages upload) | 07:46 |
fabbione | but one of them is lvm :P | 07:47 |
jbailey | Joy. | 07:47 |
jbailey | I'm hoping to send more time on EarlyUserspace this week, so I may need to poke you a bit. | 07:48 |
fabbione | jbailey: sure... | 07:49 |
fabbione | i saw that initramfs is already supported in the kerne | 07:49 |
fabbione | kernel | 07:49 |
fabbione | and there is a nice debugging message in dmesg about it | 07:49 |
jbailey | Right. I've been using distro Ubuntu kernels since January. | 07:49 |
fabbione | let me know when we should try to switch | 07:49 |
jbailey | NFS mount works, mounting a harddrive works. | 07:49 |
jbailey | This weeks goals are to get udev finally happy with lkh and klibc and then to make an attempt to port all the logic over from initrd-tools to initramfs for guessing the modules. | 07:50 |
jbailey | Once that happens we can just switch and be done with it. | 07:50 |
jbailey | I can do all the hotplug work as options. | 07:50 |
jbailey | (Which eventually become the default) | 07:50 |
fabbione | if initramfs needs klibc, we need to check if it is built everywhere first | 07:51 |
jbailey | http://people.ubuntulinux.org/~lamont/buildLogs/k/klibc/1.0.10-0ubuntu1/ | 07:52 |
jbailey | *success* | 07:52 |
fabbione | i need to build that version on sparc | 07:52 |
fabbione | the one before was FTBFS | 07:52 |
jbailey | Yar. | 07:53 |
fabbione | just creating the chroot right now :) | 07:53 |
fabbione | unfortunatly klibc is in universe | 07:53 |
fabbione | and it takes ages to get there again | 07:53 |
fabbione | remember you will need to seed it to main before switching over | 07:53 |
jbailey | I will start begging on my knees for you to post logs to where the rest of them are. | 07:53 |
fabbione | otherwise we will seriously make boom boom | 07:53 |
jbailey | It simply doesn't occur to me to look elsewhere most of the time. | 07:53 |
fabbione | jbailey: i did talk with elmo already about it | 07:53 |
fabbione | but he didn't give me a full solution yet | 07:54 |
fabbione | jbailey: i understand perfectly the problem | 07:54 |
fabbione | lamont has the same issue | 07:55 |
fabbione | for hppa | 07:55 |
fabbione | i will try to ping elmo again today | 07:55 |
jbailey | Well, he will once he starts to actually build things.. ;) | 07:55 |
fabbione | because it's in everyone interest | 07:55 |
=== jbailey hides. | ||
fabbione | ehehe | 07:55 |
fabbione | Get:20 http://debdev.ext.fabbione.net breezy/universe linux-headers-2.6.12-1 2.6.11.92-1.1 [6290kB] | 07:56 |
=== fabbione thinks... | ||
fabbione | we will need the new kernel in main to move klibc | 07:56 |
fabbione | also.. remember that these headers are not final yet | 07:56 |
fabbione | so stuff might break for little while :) | 07:57 |
jbailey | udev will move klibc. | 07:57 |
jbailey | THe kernels will pull in mkinitramfs eventually which will also bring them in. | 07:57 |
jbailey | Which headers? | 07:57 |
jbailey | Oh, Isee. | 07:57 |
jbailey | right. | 07:57 |
jbailey | Right now I'm using lkh for everything else. I pulled in the real headers for this one to avoid the hacking hassle. | 07:58 |
jbailey | I now have commit rights to upstream lkh, which will be very helpful. | 07:58 |
fabbione | right | 07:58 |
fabbione | but real kernel headers come from me | 07:58 |
jbailey | Upstream linux-libc-headers, rather. | 07:58 |
jbailey | Right, but lkh ought to be good enough for everything. | 07:59 |
fabbione | good :) | 07:59 |
jbailey | Any place where it isn't is a place wher eI'm going to get a bug at some point. | 07:59 |
jbailey | I'm using the linux-libc-headers project becaus eI'm hoping he'll get enough distros using it that it becomes the ABI headers. | 07:59 |
fabbione | specially because we want to avoid to have a huge circular b-d on the kernel | 07:59 |
jbailey | It's annoyingly unlikely, but he's kept at it for a year. There's two distros using it now. | 08:00 |
fabbione | kernel -> klibc -> initramfs (to boot/install the kernel) | 08:00 |
jbailey | He's hoping to bring Gentoo on board. | 08:00 |
jbailey | Err. the kernel shouldn't dep on klibc. | 08:00 |
jbailey | it should dep on initramfs-tools | 08:00 |
fabbione | In file included from system.c:13: | 08:00 |
fabbione | ../include/signal.h:81: warning: 'struct sigaction' declared inside parameter list | 08:00 |
fabbione | ../include/signal.h:81: warning: its scope is only this definition or declaration, which is probably not what you want | 08:00 |
fabbione | system.c: In function 'system': | 08:00 |
fabbione | system.c:19: error: storage size of 'ignore' isn't known | 08:00 |
fabbione | system.c:19: error: storage size of 'old_int' isn't known | 08:00 |
fabbione | system.c:19: error: storage size of 'old_quit' isn't known | 08:00 |
jbailey | Hah, joy. | 08:01 |
fabbione | no but klibc needs the kernel to build :) | 08:01 |
jbailey | That means the real kernel headers are fucked. | 08:01 |
fabbione | jbailey: mostlikely yes.... | 08:01 |
jbailey | I'll get off my ass and clean up all the signal/socket stuff then. | 08:01 |
jbailey | That's the bits that I had to pull in the real headers for anyway. | 08:01 |
fabbione | jbailey: i think it is more wise to make klibc to use l-k-h or whatever you had in your mind | 08:01 |
jbailey | Upstream for llh stubbed them out because glibc provides it all in private headers. klibc assumes the use of upstream. | 08:02 |
fabbione | because the kernel changes too fast for userland to follow | 08:02 |
jbailey | Yes and no. | 08:02 |
fabbione | and even a security update can mess up that stuff | 08:02 |
jbailey | If the C library can't keep up with the kernel abi, then nothing can. | 08:02 |
jbailey | Esp. the C library that's intended to be bundled with the kernel. =) | 08:03 |
fabbione | ehhe | 08:04 |
jbailey | Sometime in June is when you drop devfs support, right? | 08:05 |
jbailey | Want to try to make it a goal for Monday next week? =) | 08:05 |
fabbione | jbailey: i will drop devfs together with upstream | 08:15 |
jbailey | What?!? You're not going to be a bastard and drop it a release early like you did with ipchains/ipfwadm?? | 08:15 |
=== jbailey grumps. | ||
jbailey | =) | 08:16 |
ajmitch | people still use devfs? | 08:18 |
fabbione | jbailey: "release early" was only a patch from upstream :) | 08:18 |
fabbione | but if you like i can drop it right away | 08:19 |
=== Seveas [~seveas@dyn127.roaming.few.vu.nl] has joined #ubuntu-toolchain | ||
=== chmj [~d3vic3@dumbledore.hbd.com] has joined #ubuntu-toolchain | ||
fabbione | doko: ping? | 11:49 |
fabbione | /usr/bin/ld: /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib/crt1.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC | 11:49 |
fabbione | /usr/lib/gcc/x86_64-linux/3.4.4/../../../../lib/crt1.o: could not read symbols: Bad value | 11:49 |
doko | hmm, which package? | 11:50 |
fabbione | the package is not in the archive yet | 11:51 |
fabbione | but it builds fine on all other arches | 11:51 |
fabbione | modulo ia64 | 11:51 |
fabbione | the source is in my home dir on concordia, if you want to look at it | 11:51 |
fabbione | but from the error it looks like gcc-3.4 is borked on amd64 | 11:52 |
fabbione | doko: it happens with gcc-3.3 too | 11:57 |
fabbione | but the code is compiled with -fPIC | 11:57 |
doko | some assembler code? | 11:58 |
fabbione | doko: apparently now | 12:02 |
fabbione | not | 12:02 |
doko | any libs involved? | 12:03 |
fabbione | doko: it's building a lib | 12:04 |
fabbione | actually.... | 12:06 |
Kamion | jbailey: the ssh thing can't be your fault; it's happening in Debian too | 12:07 |
doko | fabbione: let have me a look later this weej | 12:08 |
fabbione | doko: nah i think i did something royally stupid merging some changes from upstream | 12:08 |
fabbione | and it shows up only on amd64 | 12:09 |
fabbione | yeah.. it builds fine | 12:09 |
fabbione | sorry for the mess :(((( | 12:09 |
fabbione | elmo: can you please install libxml2-dev in breezy-ppc64 chroot on davis? | 12:16 |
fabbione | (and also kernel build-deps) | 12:16 |
fabbione | ah hold on... today is holidays in uk... | 12:17 |
fabbione | crap | 12:17 |
fabbione | yeah | 12:17 |
=== Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
jbailey | fabbione: Is it something you want me to hack on? I have ppc64 locally. | 01:49 |
fabbione | jbailey: nothing urgent.. i was only trying to build the rhcluster suite on ppc64 multiarch before upload | 02:21 |
fabbione | we can do that anytime later | 02:21 |
jbailey | Ah, yeah. I could probably build it but not test it until the kernel is done. | 02:21 |
fabbione | jbailey: exactly :) | 02:21 |
fabbione | + actually the 64 bit libs are there just for fun | 02:21 |
fabbione | since no binaries need them atm | 02:22 |
jbailey | Is the cluster done in userspace or is this just hooks into the kernel? | 02:25 |
fabbione | kernel and userspace | 02:25 |
fabbione | jbailey: you around? | 03:19 |
jbailey | fabbione: Yup | 03:20 |
fabbione | jbailey: see /msg | 03:21 |
fabbione | there are more errors after that... | 03:21 |
jbailey | Bah, you should just paste in here. | 03:21 |
jbailey | But anyhow. | 03:21 |
fabbione | does it sound possible that libc6-dev is broken? | 03:22 |
fabbione | this is i386 | 03:22 |
fabbione | and i am compiling something that is absolutely unrelated to ubuntu :) | 03:22 |
jbailey | It's always possible. It's pretty rare. | 03:22 |
jbailey | LEmme see if I get the same on ppc. | 03:23 |
jbailey | (My breezy i386 system is being wiped today for a reinstall) | 03:23 |
fabbione | oh it's not redhatcluster :) | 03:23 |
fabbione | acutally you are right.. i can try that in hoary | 03:23 |
jbailey | Right, what app is it? | 03:23 |
jbailey | Works in Hoary doesn't necessarily mean correct. There's a new glibc - sometimes things change/break/whatever. | 03:23 |
fabbione | jbailey: http://gridengine.sunsource.net/servlets/ProjectSource | 03:26 |
fabbione | jbailey: there is a page where to get the tar.gz | 03:27 |
fabbione | http://gridengine.sunsource.net/servlets/ProjectDocumentList | 03:27 |
jbailey | Fatal error, aborting. | 03:27 |
jbailey | anoncvs: no such user | 03:27 |
fabbione | here is | 03:27 |
jbailey | Ah good. =) | 03:28 |
fabbione | sge-V60u4 | 03:28 |
=== jbailey fetches | ||
fabbione | hmm you need java to build | 03:29 |
jbailey | Hmm. | 03:29 |
jbailey | I wonder if gcj is good enough. | 03:29 |
jbailey | (It had better be, or this is headed to multiverse.. =( ) | 03:29 |
jbailey | What is it with people and crappy build environments? | 03:31 |
fabbione | hmm sablevm is enough | 03:31 |
jbailey | This is a *solved* problem for the most part. | 03:31 |
fabbione | and it's building in hoary | 03:31 |
jbailey | If sable can do it, then gcj/gij/ecj can. | 03:31 |
fabbione | i think java is used only in the build scripts | 03:31 |
jbailey | Which step is failing for you? | 03:31 |
fabbione | it's the usual java crap from sun to create junk that already exists outside | 03:31 |
fabbione | read source/README.build | 03:32 |
jbailey | I'm looking at that. | 03:32 |
fabbione | after you run ./aimk depend | 03:32 |
fabbione | that one completes fine | 03:32 |
jbailey | Ugh. | 03:32 |
jbailey | Needs csh | 03:32 |
fabbione | the next step is to just run ./aimk to build | 03:32 |
fabbione | it fails immediatly | 03:32 |
fabbione | at the libs | 03:32 |
fabbione | breezy.. in hoary it's building | 03:32 |
jbailey | ls | 03:33 |
fabbione | you will need libgjcX-dev | 03:34 |
jbailey | YEah, those all come as part of java-gcj-compat | 03:34 |
jbailey | _________C_O_R_E__S_Y_S_T_E_M_____________ | 03:35 |
jbailey | ../common/Makefile:67: ../common/common_dependencies: No such file or directory | 03:35 |
jbailey | hmm | 03:35 |
jbailey | Whups, had skipped a step | 03:36 |
jbailey | Wow, more errors than my terminal backscroll. =) | 03:37 |
fabbione | ehhehe | 03:38 |
fabbione | this crack makes me enjoy my pc :)))) | 03:38 |
jbailey | Lovely, I see the same error here. | 03:38 |
fabbione | good | 03:38 |
fabbione | because it's building in hoary :) | 03:38 |
fabbione | there are a few tons of build-deps... | 03:41 |
fabbione | but it's fun! :P | 03:41 |
jbailey | No definition for __const | 03:41 |
jbailey | Hmm, what should pull it in? | 03:41 |
fabbione | where do you get that? | 03:42 |
jbailey | typedef int (*__gconv_fct) (struct __gconv_step *, struct __gconv_step_data *, | 03:42 |
jbailey | __const unsigned char **, __const unsigned char *, | 03:42 |
jbailey | unsigned char **, size_t *, int, int); | 03:42 |
jbailey | That's what I get running the failing command through -E -dD | 03:42 |
jbailey | Are you familiar with those switches to gcc? | 03:43 |
fabbione | oh... | 03:43 |
fabbione | nope... | 03:43 |
fabbione | i am not a gcc/glibc expert :) | 03:43 |
fabbione | i was trying to see some of the stuff you did last time in screen :) | 03:43 |
jbailey | -E says "spit out what the compiler sees after cpp has had it's way", -dD tells it to let me know where various #defines and such happen. | 03:43 |
fabbione | at least i understood how to read -v :P | 03:43 |
jbailey | Hey glad to help where I can. =) | 03:43 |
fabbione | yeah i learn fast :) | 03:44 |
fabbione | or at least i try to | 03:44 |
jbailey | Although when doing this with glibc headers, it's often helpful to have seen them a few times before. They occasionally have crazy magic in them. | 03:44 |
fabbione | no shit :) | 03:44 |
jbailey | but gcc -E has to be something a compiler can understand, so that's where I usually start. | 03:44 |
jbailey | fabbione: Can you help me look for something? Save me loading a bunch of development crap on my wife's machine. | 03:48 |
jbailey | (It's the Hoary one, I don't have any Java dev stuff on it) | 03:48 |
jbailey | Mm, no it looks like __const is a gcc-4 builtin anyway. | 03:49 |
=== jbailey looks for something else then. | ||
fabbione | jbailey: sure.. just ask what you need | 03:52 |
jbailey | Erm, on my system anyway it seems to be prefering /usr/include/linux/stddef.h to gcc's one. | 03:56 |
jbailey | It does that with 3.3 on breezy, too. | 03:58 |
jbailey | fabbione: Do you have a build log? Can you show me the command that it's calling for that file on your hoary install? | 03:59 |
doko | is /usr/include explicitely in the include path (-I option)? | 03:59 |
jbailey | doko: It is here. | 03:59 |
jbailey | But stddef is in /usr/lib/gcc... | 04:00 |
doko | that's just wrong, gcc get's confused with include_next ... | 04:00 |
jbailey | /usr/include/linux is also explicetely in there, which is strange. I'm used to things #include <linux/FOO.h> | 04:00 |
fabbione | jbailey: yes.. in a few minutes.. i need to figure how to make clean in the source... | 04:03 |
jbailey | fabbione: rm -rf LINUXPPC_26 ? =) | 04:04 |
fabbione | jbailey: hehe possibly.. but i am almost done with the build :) | 04:05 |
fabbione | there is the need of a little patch to make it compile 100% | 04:08 |
fabbione | but that's easy :) | 04:08 |
fabbione | jbailey: it's building now.... | 04:10 |
fabbione | as soon as it's done i will upload the log | 04:10 |
jbailey | Tx. | 04:11 |
fabbione | no problem :) | 04:11 |
jbailey | My guess is that the -I flags are slightly different between the breezy and hoary versions for some reason. | 04:11 |
fabbione | hoary_log.txt | 04:12 |
fabbione | on people.u.c/~fabbione | 04:12 |
doko | -I/usr/include -I/usr/include/linux is just evil | 04:18 |
jbailey | Right, so on Hoary it's not feeling the need to include /usr/include and /usr/include/linux in the gcc command line. | 04:20 |
jbailey | fabbione: Can I leave it with you from there? I suspect once those both go away you'll be fine. | 04:22 |
lamont | doko: evil, and breaks #include_next, iirc | 04:22 |
fabbione | jbailey: sure... | 04:22 |
fabbione | i was only concerned about the error coming from a glibc include file... | 04:23 |
jbailey | fabbione: Right - I just wanted to make sure you didn't need any more info from me before I rm -rf'd my tree locally. | 04:24 |
fabbione | jbailey: if you are sure that's the problem, i am happy with that | 04:25 |
fabbione | jbailey: and i will dig from there | 04:25 |
jbailey | fabbione: Pretty certain. If you look at the failing command with -E -dD, you'll see that size_t is never definned. When you look at stddef.h, you see that it's being pulled in from /usr/include/linux instead of /usr/lib/gcc/.../include/stddef.h | 04:28 |
doko | lamont: yes, scroll back a bit more ;) | 04:29 |
jbailey | *bounce* | 04:33 |
=== jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #ubuntu-toolchain | ||
doko | lamont: thanks for the buildd toolchain love on the weekend | 04:37 |
lamont | doko: sorry that the family had me as busy as it did... | 04:39 |
doko | lamont: no reason to have an excuse for that :-) | 04:44 |
fabbione | jbailey: that's right... eliminating the -I/usr/include/linux is the right solution | 04:52 |
fabbione | the real problem is that i can't find a single reference to it in the entire source | 04:52 |
jbailey | fabbione: I don't know how to troubleshoot csh. | 04:56 |
fabbione | nah don't worry :) it was just to keep you informed :) | 04:56 |
fabbione | this build system is worst than imake :) | 04:57 |
jbailey | I apprecaite it. I was curious so I looked. | 04:57 |
jbailey | I enjoy fiddling with build systems. I suspect this fix will be more than fiddling. =) | 04:57 |
fabbione | AHHHHHH | 05:21 |
fabbione | if ("$JAVA_ARCH" != "") then | 05:21 |
fabbione | set CORE_INCLUDE = "$CORE_INCLUDE -I${JAVA_HOME}/${JAVA_INCL}/${JAVA_ARCH}" | 05:21 |
fabbione | endif | 05:21 |
fabbione | this one! | 05:21 |
fabbione | jbailey: for some incredible reasons that entry becomes /usr/include/linux | 05:21 |
fabbione | but it's not meant to | 05:21 |
fabbione | (btw csh accepts -x as bash | 05:22 |
fabbione | ) | 05:22 |
=== jbailey blinks. | ||
jbailey | It's not something that holds over in $CORE_INCLUDE from before? | 05:23 |
fabbione | i mean.. really.... | 05:23 |
jbailey | Mm, no, I guess I can see it. | 05:23 |
fabbione | basically CORE_INCLUDE is expanede with -I${JAVA_HOME}/${JAVA_INCL}/${JAVA_ARCH} | 05:23 |
jbailey | JAvA_HOME might be blank | 05:23 |
fabbione | when JAVA_HOME is not empty | 05:23 |
fabbione | but it is empty | 05:23 |
jbailey | JAVA_INCL for gcj might be /usr/include | 05:24 |
doko | fabbione: use java-gcj-compat and set JAVA_HOME=/usr/lib/jvm/gcj-java ... | 05:24 |
fabbione | if ( $JAVA > 0 || $BUILDJAVADOC == 1 || $JNI == 1 ) then | 05:24 |
fabbione | # Make sure we can find JAVA_HOME | 05:24 |
fabbione | if ( ${?JAVA_HOME} == 0 ) then | 05:24 |
fabbione | echo "Please set JAVA_HOME" | 05:24 |
fabbione | exit 1 | 05:24 |
fabbione | endif | 05:24 |
fabbione | endif | 05:24 |
fabbione | so this check fails | 05:24 |
fabbione | there we go :) | 05:25 |
fabbione | sick sick sick | 05:25 |
fabbione | cat build-progress | 05:29 |
fabbione | glibc_2.3.5-1ubuntu4: successful | 05:29 |
fabbione | yay! | 05:29 |
doko | jbailey, time for the next glibc upload, i386 biarch/multiarch ;) | 05:32 |
fabbione | doko: die! | 05:33 |
fabbione | first sparc needs to change to NTPL | 05:33 |
fabbione | or whatever is called :) | 05:34 |
fabbione | doko: sparc just started building gcc-3.4 | 05:34 |
fabbione | do i need to stop it, or can i let it build? | 05:34 |
doko | fabbione: do you need it? | 05:34 |
fabbione | stop in the meaning of = do you plan an upload within the next 12 hours? | 05:35 |
doko | no, why do you need the latest build on sparc? | 05:35 |
fabbione | doko: i need to get the build fixes from the proper sources... | 05:35 |
fabbione | the previous one was manually munged to make it build :) | 05:35 |
doko | ahh, ok | 05:35 |
fabbione | and it's not nice if sources and binaries do not match | 05:35 |
fabbione | it would also be very nice if we can get the new gcc-4.0 in, to fix the /usr/lib64 /usr/lib thingy... | 05:36 |
jbailey | doko: amd64/i386 multiarch would make more sense to do next. It's an underused arch if we break it, and it gets you OO.o2 stuff you need. | 05:42 |
jbailey | doko: I'd like to get a few EarlyUserspace things done first, though. | 05:42 |
jbailey | fabbione: Sparcs conversion to nptl is dep's on binutils-2.16 | 05:44 |
jbailey | doko: BTW, what do you think of the ia64 workaround bit that I mentioned? That the testsuite failure goes away if I do a build cycle of binutils, glibc against new binutils and then new binutils again. | 05:44 |
fabbione | jbailey: ok :) | 05:46 |
infinity | jbailey : That's not surprising at all. | 05:51 |
infinity | jbailey : Makes me wonder if maybe our scorched earth bootstrapping shouldn't involve a sick round-robin of gcc/binutils/glibc builds for a few months before we build anything else. :) | 05:52 |
fabbione | infinity: eheheh | 05:52 |
fabbione | and pleople still believes i am sick... | 05:53 |
fabbione | somebody is beating me | 05:53 |
fabbione | well nice... | 05:54 |
fabbione | now the gridengine is built :) | 05:54 |
fabbione | tomorrow we will learn how a computing cluster grid will work :) | 05:54 |
fabbione | thanks a lot guys :) | 05:56 |
fabbione | i am off for dinner | 05:57 |
jbailey | infinity: I beleive that it does - lamont doesn't usually install our binaries in the chroots, but instead rebuilds them with the binaries we provided and installs those in the chroots. | 06:09 |
jbailey | infinity: But the concern I have is inheriting bugs. | 06:09 |
jbailey | infinity: So some interaction that causes ABI instability of some sort that gets inherited down. | 06:09 |
jbailey | infinity: (Given that the testsuite failure is something in static linking. I don't have the error in front of me...) | 06:10 |
infinity | Oh, fun. | 06:19 |
jbailey | I think it's probably not in this case. I suspect it's a TLS fix on a static library that is being made correct. | 06:25 |
doko | I've merged these patches to 2.16. 2.16.1 is almost ready now; I'm hoping | 06:28 |
doko | to release it on Friday. | 06:28 |
doko | -- | 06:28 |
doko | Daniel Jacobowitz | 06:28 |
doko | jbailey: ^^^ | 06:28 |
doko | so maybe we can wait until the next weekend? | 06:29 |
=== \sh [~shermann@server3.servereyes.de] has joined #ubuntu-toolchain | ||
\sh | I need some advise | 06:38 |
\sh | ../Ark/ArkObject.h:100: error: 'Cache' has not been declared | 06:39 |
\sh | ../Ark/ArkObject.h:108: error: 'Cache' has not been declared | 06:39 |
jbailey | \sh: Context? =) | 06:53 |
jbailey | doko: That's fine. I'm in no rush for it. | 06:55 |
=== jbailey checks ToolchainTransition | ||
\sh | jbailey: virtual bool Load (Cache *cache, const String &name); | 06:57 |
\sh | the second line is the same thing.. | 06:57 |
\sh | Ark::Cache is included | 06:58 |
\sh | its all in a namespace named Ark | 06:58 |
jbailey | \sh: Right. So is there a declaration of Cache before that in that namespace? | 06:58 |
jbailey | \sh: g++ -E -dD is your friend here... | 06:58 |
\sh | nope | 06:58 |
jbailey | Hmm, I wonder if there's a post-processing phase for g++ where you can see all the calls with namespaces expanded. | 06:59 |
jbailey | doko: Neat. Looks like after the binutils update that we might be ready to ask for the rebuild of the world to verify that everything's transitionned. | 07:00 |
=== doko [~doko___@dsl-084-059-056-028.arcor-ip.net] has joined #ubuntu-toolchain | ||
doko | lamont: please could you remove the dep-wait from ftgl? | 07:48 |
doko | infinity: ^^^ | 08:10 |
lamont | doko: done | 08:18 |
doko | jbailey: I'd like to wait with the rebuild for gcc 4.0.1, announced for mid June | 09:20 |
doko | lamont: thanks | 09:20 |
jbailey | doko: That works, I saw Mark's email this morning about it. | 09:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!