**** BEGIN LOGGING AT Tue May 17 23:59:56 2005 May 18 05:41:04 anybody did a full build in the last 18hours? mine is still busted. The #OE guys said they posted the fix but a pull doesn't show it. May 18 05:45:27 It looks like an infrastructure issue as a new build won't even get past quilt-native. May 18 05:45:55 I get lots of python errors and the last one is: AttributeError: 'module' object has no attribute 'createCopy' May 18 05:51:37 <[g2]> VoodooZ_Work, why aren't you using the tarball ? May 18 05:52:35 Still. I haven't changed anything in the last 2 weeks. I just do a pull/full build everyday or so and it failed. May 18 05:52:53 I'll check it out but with all the private changes I have It's not worth it. May 18 05:53:08 <[g2]> VoodooZ_Work, I understand. It's only been that way for what, the last 8-9 months ? May 18 05:53:28 <[g2]> with minor breakage every other weeks May 18 05:53:31 <[g2]> with minor breakage every other week May 18 05:53:57 It's definitely an #OE breakage though. It's probably just a new bitbake version or something. May 18 05:54:29 Somebody in OE just said it was the case so I'll try it. May 18 05:54:44 Now, I have to remember how to update bitbake! :) May 18 05:55:06 <[g2]> tracking changes is important May 18 05:55:23 <[g2]> you can pull a specific version of bitbake May 18 05:56:08 I'll just get the latest for now as they said a lot of work had been done in the last day. May 18 05:56:09 brb May 18 06:07:42 sorry May 18 11:19:37 The OE gnu-config build break in in machine/nslu2.conf, I've confirmed unslung with the fix but need to validate openslug and openslug-uclibc, then I'll push it. You need an up-to-date bitbake *as well*. May 18 11:21:25 beewoolie: your PATH problem may be a result of having a setting in .bashrc (or whatever the .rc file is for the shell which is used.) It's fine to build from the SVN trunk (trunk/openslug), it matches 1.12 at present. May 18 14:49:29 Good Evening (for an EDT value of evening) May 18 14:51:17 hi CW May 18 14:53:19 has anyone heard of problems with a symbol named __udivsi3? May 18 14:55:26 perl claims it's undefined in libperl.so.5, but net searches are split between a link error and a kernel bug. May 18 14:56:11 (the kernel bug was pretty old, so maybe n longer an issue) May 18 15:04:04 hmm May 18 15:04:41 I think where it's defined depends on hard/soft float May 18 15:05:22 in a hard-float system, it would be in the kernel float emulation, on soft-float, it would be in glibc May 18 15:11:46 I built a default 4.0 beta openslug snapshot, if that helps May 18 15:11:51 It's the implementation of 32 bit unsigned division. May 18 15:12:17 It should be in something very low level (libgcc?) May 18 15:12:36 a slug is soft-float, yes? May 18 15:13:12 "4.0 beta openslug snapshot" May 18 15:13:13 ? May 18 15:13:26 unslung is 4.x, openslug is 1.x May 18 15:13:34 which do you mean? it makes a difference May 18 15:14:15 sorry, brain fade... 1.x beta release (the source tgz as of the mailing list announcement) May 18 15:14:19 a slug is hardware without a FPU, but that is not the same as saying it's "soft-float" May 18 15:14:26 openslug, to be sure May 18 15:14:49 and it gets more complex... May 18 15:15:19 understood. perl is the only program complaining, so maybe the link is frobbed? May 18 15:15:31 in unslung, even tho we are using a soft-float toolchain, glibc 2.2.5 does not sully support soft-float, so the kernel must have an amulator builtin - in this case NWFPE May 18 15:16:10 in openslug, glibc 2.3.x *does* support soft-float well enough that the kernel does not need the emulator, tho I think it's built in anyway May 18 15:16:48 that makes be believe it's a linking problem in perl. May 18 15:17:09 considering nothing else seems broken May 18 15:17:15 now, I've built perl on both unslung and openslug and run the testsuite, and current releases of both dists should test out 100% May 18 15:17:30 this makes me think it's something in the way oe is building perl May 18 15:17:41 I've never gotten an oe-built perl to test out May 18 15:17:47 on either slug dist May 18 15:17:51 Yes, make sure the link has '-lgcc' (I thought gcc added this by default, but if perl uses ld that might explain it). BTW it's not FP May 18 15:18:31 jbowler, ah I misread - is that integer div ? May 18 15:19:05 I sorta guessed that. :) May 18 15:19:07 unsigned integer May 18 15:19:08 in which case all the FP stuff I said is irrelavant May 18 15:19:16 dammit May 18 15:19:19 irrelevant May 18 15:20:07 but what I said about never having a successful test of oe-built perl still applies May 18 15:21:33 Ok, here's an example, tfoo.c is the program: int main(void) { unsigned int a, b; return a/b; } May 18 15:21:37 Then the output is: May 18 15:21:52 openslug:/home/work-tmp/jbowler/nslu2/test $ armeb-linux-gcc -o tfoo tfoo.c May 18 15:21:52 openslug:/home/work-tmp/jbowler/nslu2/test $ armeb-linux-gcc -c tfoo.c May 18 15:21:53 openslug:/home/work-tmp/jbowler/nslu2/test $ armeb-linux-gcc -o tfoo tfoo.o May 18 15:21:54 openslug:/home/work-tmp/jbowler/nslu2/test $ armeb-linux-ld -o tfoo tfoo.o May 18 15:21:56 armeb-linux-ld: warning: cannot find entry symbol _start; defaulting to 00008074 May 18 15:21:58 tfoo.o(.text+0x18): In function `main': May 18 15:22:00 tfoo.c: undefined reference to `__udivsi3' May 18 15:22:02 o May 18 15:22:31 I.e. gcc is adding some -lfoo to the ld command line for the relevant library. Not sure it's -lgcc 'cause I can't find one of those. May 18 15:23:32 -lgcc_s ? May 18 15:23:51 looking at the makefile left over in the build, I don't see libgcc anywhere in the libs_wanted line. May 18 15:24:42 should be done automatically, config'd in the gcc specs file IIRC May 18 15:26:46 libgcc.a contains the out-of-line ops (of which this is one) and it is in the 'cross' directory, but I can't find it in staging (this is probably correct) May 18 15:27:30 CodeWhacker: the makefile shouldn't reference it, it's specific to the compiler. Use gcc instead of ld - i.e. set LD=gcc May 18 15:28:02 ... you may need to modify other stuff too, if perl is doing something very compiler specific at the link stage May 18 15:28:35 ~perl's buildsystem May 18 15:28:45 sigh, no damn bot May 18 15:28:57 ah. good point May 18 15:32:32 CodeWhacker, how are you building this perl? May 18 15:33:20 just as it's build with a naked 'make' in the root directory of the tree. Nothing fancy May 18 15:34:10 so you are native building it ? May 18 15:34:22 or cross? May 18 15:34:37 it's cross. I have an x86 host. May 18 15:35:27 oh May 18 15:35:52 how far is the build getting? May 18 15:36:38 it completes without error, but the resulting .ipk, when I install it on the slug, fails with an undefined symbol error. May 18 15:37:03 oh so it *is* under oe May 18 15:37:25 for a sec I thought you were trying to cross-build with just a cross-toolchain May 18 15:37:29 yes it is. can you point me to the magic file? May 18 15:37:41 magic file? May 18 15:37:56 where I can add a specific lib dependency May 18 15:38:14 * CodeWhacker got dumb these past months ;) May 18 15:41:39 The shared library lib dependencies (RDEPENDS) are generated automatically. It sounds like the .shlibdeps is wrong (in the work install directory), it should at least contain the following two lines: May 18 15:41:40 libgcc1 (>= 3.4.3) May 18 15:41:41 libc6 (>= 2.3.2+cvs20040726) May 18 15:42:54 It's the first (libgcc1) line which might be missing somewhere. If so it implies that the build failed to include the NEEDS line (or something like that) in the linked output (.so or executable) May 18 15:45:28 hmmm... no .shlibdeps to be found, according to `find` May 18 15:47:25 bbiab May 18 15:47:30 It's a file name extension (to the name of the relevant package, if there are multiple executables in a single package that might hide an error in one of them). **** ENDING LOGGING AT Wed May 18 23:59:57 2005