**** BEGIN LOGGING AT Fri Oct 02 02:59:56 2009 Oct 02 05:20:32 03Klaus Kurzmann  07shr/import * r3c1ef3d748 10openembedded.git/recipes/efl1/elementary_svn.bb: Oct 02 05:20:32 elementary: add efreet as dependency as it needs it now Oct 02 05:20:32 Signed-off-by: Klaus Kurzmann Oct 02 06:23:43 03Khem Raj  07org.openembedded.dev * r31d07ca916 10openembedded.git/recipes/uclibc/ (4 files in 2 dirs): Oct 02 06:23:43 uclibc-nptl: Move to latest revision. Oct 02 06:23:43 * Add needed fixes to get uclibc nptl compiling. Oct 02 06:23:43 Signed-off-by: Khem Raj Oct 02 06:23:54 03Khem Raj  07org.openembedded.dev * r8edf0c3c88 10openembedded.git/recipes/proxy-libintl/proxy-libintl_20080418.bb: Oct 02 06:23:54 proxy-libintl_20080418.bb: include libintl.h in -dev package. Oct 02 06:23:54 Signed-off-by: Khem Raj Oct 02 06:23:54 03Khem Raj  07org.openembedded.dev * r8525f8ccc1 10openembedded.git/recipes/eglibc/eglibc_svn.bb: Oct 02 06:23:56 eglibc-svn: Bump the SRCREV to latest. Oct 02 06:23:58 Signed-off-by: Khem Raj Oct 02 06:35:12 good morning Oct 02 06:40:51 Morning ..... Oct 02 06:41:15 How do I specify a LD_LIBRARY_PATH for openembedded to use when generating SO_NEEDED Oct 02 06:43:25 sgh: haeh? Oct 02 06:43:49 sgh: SO_NEEDED comes from passing -l to the compiler/linker? Oct 02 06:44:01 sgh: my closest guess is you want to have man ld and search for rpath-link Oct 02 06:45:19 zecke: the case it that I have a recepi containing libs in /usr/lib/vtk-5.4.2 Oct 02 06:46:02 sgh: /usr/lib of the host? Oct 02 06:46:11 zecke: no the target image Oct 02 06:46:32 zecke, wrt the git problems I had a few days ago: apparently opensuse 11.1 git was broken, I moved to the latest version and the problem was gone Oct 02 06:46:51 eFfeM: cool Oct 02 06:51:18 Hasse_: Hi Oct 02 06:52:42 sgh: yo, champ! :) Oct 02 06:54:47 Hasse_: :) Oct 02 06:59:00 sgh: and your problem is that you need LD_LIBRARY_PATH on the device now Oct 02 06:59:13 sgh: option a) write a /etc/ld.so.conf Oct 02 06:59:48 sgh: option b) make the code emit a rpath (which is always a bit problematic) Oct 02 07:02:19 zecke: ok ... also the package is not installed in the image because oe does not find the libraries during build. Apparently as I understand RDEPEND and DEPEND is not forced installed in the image. Oct 02 07:03:41 sgh: RDEPENDS are forced Oct 02 07:04:00 sgh: well, OE will print a big warning when it doesn't find a provider. Did it print it? Oct 02 07:05:05 zecke: "which vtk" selects the correct package, so it should be ok. Oct 02 07:06:21 sgh: these are two different things. If your binary has a SO_NEEDED libvtk.so.A.B.C... there are two possible outcomes Oct 02 07:06:35 sgh: 1.) your package has a dependency on the provider of libvtk.so.A.B.C Oct 02 07:06:48 sgh: 2.) OE warns you it can not find a provider Oct 02 07:07:49 sgh: ... ok ... I think the easiest solution for me is to move the libraries to /usr/lib .... thanks for your help. Oct 02 07:08:18 sgh: most likely Oct 02 07:19:19 zecke: recipes/glibc contains several ld.so.conf files. Which on is chosen during the build of glibc-2.9 ? Oct 02 07:20:27 sgh: in most cases none :) Oct 02 07:26:44 I'm trying to figure out what script in the console-image thats mounting all my partitions into /media/hdaX.. I don't want all partitions to be mounted so I need to get rid of that script.. But I can't find it.. Any idea where to look for it? Oct 02 07:27:32 sgh: with more text: In most cases (with hwcaps disabled glibc) ld.so.conf is adding more overhead then just searching in /lib and /usr/lib, this is why we don't install it in some configs Oct 02 08:13:51 03Steve Sakoman  07org.openembedded.dev * r83b0a50036 10openembedded.git/ (conf/checksums.ini recipes/gnome/gnome-applets_2.28.0.bb): gnome-applets: add 2.28.0 Oct 02 08:13:52 03Steve Sakoman  07org.openembedded.dev * r64e2f9d24c 10openembedded.git/ (2 files in 2 dirs): gnome-control-center: add 2.28.0 Oct 02 08:13:53 03Steve Sakoman  07org.openembedded.dev * r10a30eb198 10openembedded.git/ (9 files in 3 dirs): gdm: add 2.28.0 Oct 02 08:13:54 03Steve Sakoman  07org.openembedded.dev * r4e9f41a8c6 10openembedded.git/ (conf/checksums.ini recipes/gnome/libgnomekbd_2.28.0.bb): libgnomekb: add 2.28.0 Oct 02 08:13:56 03Steve Sakoman  07org.openembedded.dev * r2b8c4801d5 10openembedded.git/ (conf/checksums.ini recipes/gnome/libgnome_2.28.0.bb): libgnome: add 2.28.0 Oct 02 08:13:59 03Steve Sakoman  07org.openembedded.dev * r37e4d79aed 10openembedded.git/ (2 files in 2 dirs): gnome-settings-daemon: add 2.28.0 Oct 02 08:14:02 03Steve Sakoman  07org.openembedded.dev * r4db6d500c2 10openembedded.git/recipes/xorg-lib/libxrandr_1.3.0.bb: libxrandr: add 1.3.0 Oct 02 08:14:05 03Steve Sakoman  07org.openembedded.dev * r15b1baa6f5 10openembedded.git/ (conf/checksums.ini recipes/gnome/gnome-common_2.28.0.bb): gnome-common: add 2.28.0 Oct 02 08:14:08 03Steve Sakoman  07org.openembedded.dev * r6ee24bc575 10openembedded.git/recipes/gnome/gnome-desktop_2.28.0.bb: gnome-desktop: add 2.28.0 Oct 02 08:14:15 03Koen Kooi  07org.openembedded.dev * r38db27a2d6 10openembedded.git/ (4 files in 2 dirs): Oct 02 08:14:18 connman: update git version Oct 02 08:14:20 connman-gnome: update git version Oct 02 08:14:22 03Koen Kooi  07org.openembedded.dev * rb3fbc73ea7 10openembedded.git/contrib/angstrom/build-feeds.sh: angstrom feed builder: also build xf86-input-evtouch Oct 02 08:14:25 03Koen Kooi  07org.openembedded.dev * rc4f2be3ae0 10openembedded.git/recipes/xorg-driver/ (10 files in 3 dirs): xf86-input-evtouch: make it build again, add HAL support Oct 02 08:30:39 Hi, I would like to think that I am getting to grips with elinux, but there is still much to learn. I have built the qte sdk from the dev branch, but I am unsure what version of qte it is using, is there a straight forward way of identifying the version? Oct 02 08:31:02 4.5.2 Oct 02 08:31:10 look at the recipe Oct 02 08:32:12 I looked at the meta-toolchain-qte recipe but there was not a version number Oct 02 08:32:42 you know the word meta? Oct 02 08:33:47 ok... Oct 02 08:34:17 *feeling a little uncomfortable right Oct 02 08:34:27 *now Oct 02 08:35:32 I must admit I do not know what the meta represents Oct 02 08:36:17 the meta recipes includes the packages which is needed to the qte toolchain? Oct 02 08:37:11 bitbake -i Oct 02 08:37:17 peek qt4-embedded PV Oct 02 08:49:34 good morning Oct 02 08:50:38 hi ant Oct 02 08:52:26 woglinde: Sorry didint mean to be rude and run away, lost my connection. Back to qte, this would be the source of my problem, I built a small app using the SDK, but I was getting errors. My beagleboard has qte installed but it is version 4.4.1, will obviously need to build the latest version for Angstrom Oct 02 08:52:56 right Oct 02 08:53:05 latest in oe is 4.5.2 Oct 02 09:24:14 How do I control the installationg sequence of packages in my image. I want to do manioulations to the image before packaging it into tar,ext,jffs2 etc ? Oct 02 09:26:28 morning Oct 02 09:33:42 What do_* functions are called as a part of generating the final image ? Oct 02 09:34:24 sgh: try IMAGE_POSTPROCESS Oct 02 09:34:44 sgh: err, IMAGE_POSTPROCESS_COMMAND Oct 02 09:34:56 it's a command that's run before making rootfs images Oct 02 09:36:08 so you can e.g. define a function my_tweak() { ... } and then IMAGE_POSTPROCESS_COMMAND += "my_tweak;" Oct 02 09:40:48 akheron: that is jsut a command of my choice ? Oct 02 09:41:03 yes Oct 02 09:41:29 akheron: great. thanks Oct 02 09:55:43 morning lrg__ Oct 02 09:56:08 hi pb Oct 02 09:56:13 and rkirti Oct 02 09:56:16 morning pb__ Oct 02 09:56:28 hi woglinde Oct 02 09:56:40 hello woglinde Oct 02 09:56:47 morning pb__ Oct 02 10:02:53 pb__: question about gcc... I'm pretty sure I set -nostartfiles -nostdlib -nodefaultlibs as linking options and -nostdinc for compiler, still it seems to link to libgcc (memcpy was previously defined..) Oct 02 10:03:04 any idea? Oct 02 10:04:55 btw, no, I don't set -lgcc Oct 02 10:06:06 look at the Makefile Oct 02 10:06:24 eh..I'm patching it... Oct 02 10:06:56 http://tinyurl.com/y9q6z7t Oct 02 10:07:00 last lines Oct 02 10:07:36 ant_work: memcpy isn't in libgcc. are you sure this is the cause of your problem? Oct 02 10:07:50 you can inspect what libraries gcc is actually asking the linker to include by running the final link with --verbose Oct 02 10:07:58 03Klaus Kurzmann  07shr/import * r3ac7b91925 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Oct 02 10:07:58 preferred-shr-versions: bump vala to 0.7.7 Oct 02 10:07:58 Signed-off-by: Klaus Kurzmann Oct 02 10:08:04 03Frederik Sdun  07shr/import * rd2bc623e7a 10openembedded.git/recipes/vala/ (6 files in 2 dirs): Oct 02 10:08:04 Add vala 0.7.7 Oct 02 10:08:04 Signed-off-by: Frederik 'playya' Sdun Oct 02 10:08:05 Signed-off-by: Klaus Kurzmann Oct 02 10:08:20 pb__: my doubt is about the options...these are for klcc Oct 02 10:08:26 those look fine Oct 02 10:08:40 what is the actual error that you see? Oct 02 10:09:13 he..I have logs @home Oct 02 10:09:26 basic problem is the lack of sys/types (klibc) Oct 02 10:09:54 then I remember I saw gcc4.3.3 in the -I paths... :/ Oct 02 10:11:33 and errors because memcpy /memcmp was already defined Oct 02 10:13:07 03Koen Kooi  07org.openembedded.dev * r979a428c85 10openembedded.git/recipes/gnome/gnome-desktop.inc: gnome-desktop: tweak packaging Oct 02 10:13:08 03Koen Kooi  07org.openembedded.dev * r0d79048113 10openembedded.git/ (12 files in 4 dirs): network manager: massive update Oct 02 10:13:08 03Koen Kooi  07org.openembedded.dev * r4a520da6d6 10openembedded.git/classes/gnome.bbclass: gnome bbclass: tweak mime packaging Oct 02 10:13:09 03Koen Kooi  07org.openembedded.dev * r8fec15f70d 10openembedded.git/classes/package.bbclass: package bbclass: fix static libs logic Oct 02 10:13:12 03Koen Kooi  07org.openembedded.dev * r36f7e05cce 10openembedded.git/recipes/pulseaudio/libcanberra_0.17.bb: libcanberra: tweak packaging Oct 02 10:13:22 hej, just for clarification, bugs (i.e. with already fixing patch) are filed in bugzilla, or are the best shared at patch queue (for oe developers?), or mailinglists ? what may be the fastest way to get them approved ? Oct 02 10:13:41 mailinglist and poking devs Oct 02 10:13:52 ;) Oct 02 10:14:06 I read that with -nostdlib one has to provid the entrypoints for "memcmp", "memset", "memcpy" and "memmove"...and purgatory provides these in string.c Oct 02 10:15:04 mlip: the bugtrackker has basically collapsed under its own weight, so mailing list Oct 02 10:15:07 ant_work maybee I header problem? Oct 02 10:15:13 for sure :) Oct 02 10:15:16 mlip: preferably in git format-patch format Oct 02 10:15:30 ant_work whats purgatory including? Oct 02 10:16:01 woglinde: problem is sys/types Oct 02 10:16:18 -> posix -> asm types Oct 02 10:16:42 other two headers were 'staged' by the patch...probably I need a third Oct 02 10:16:45 XorA: thx, tried to use the bugtracker (a few times now) , but basically got no respones Oct 02 10:19:05 * XorA gueses thats another OEDEM topic, WTF to do with the next to useless bugtracker Oct 02 10:20:03 woglinde: I just need small bits.. size_t uint32_t uint8_t uintptr_t Oct 02 10:20:43 (if I'm not totally wrong ;) Oct 02 10:25:58 woglinde: last but not least, it seems there are problems with klibc headers Oct 02 10:25:59 http://www.zytor.com/pipermail/klibc/2009-September/002457.html Oct 02 10:26:38 iirc khem too would suggest "make headers_install" for all *libc Oct 02 10:27:46 akheron: Do I need to do somethin special to use EXPORT_FUNTIONS in an image-definition Oct 02 10:28:49 why would you export a function in an image recipe? Oct 02 10:29:16 ant jo Oct 02 10:32:46 woglinde: so, where should I copy the uint*.. defs? from kernel headers? klibc is machine-specific Oct 02 10:32:55 ???? Oct 02 10:32:56 ant Oct 02 10:33:05 ant show me exactly the problem now Oct 02 10:33:24 don't have buildsystem here, sorry Oct 02 10:33:30 can't be precise Oct 02 10:34:31 hmmm, super cutdown eglibc needed for initrams :-) Oct 02 10:34:41 instead of unmaintained klibc Oct 02 10:34:43 xora???? Oct 02 10:34:46 ah Oct 02 10:34:48 *g* Oct 02 10:34:49 woglinde: easy would be for you to try to compile the recipe ;) Oct 02 10:34:59 you could even use dietlibc Oct 02 10:35:03 I should update it Oct 02 10:35:22 woglinde: that would probably make more sense, klibc is a) attrocious and b) unmaintained Oct 02 10:35:38 woglinde: I'm repeating the steps/hacks who let the kexec-tools-1.101 compile Oct 02 10:35:45 I'm almost there... Oct 02 10:36:02 but I don't have the whole picture, not yet... Oct 02 10:36:16 (compilcated sources...) Oct 02 10:37:14 I suppose I have to a) stage the missing header b) include klibc dir with -I Oct 02 10:37:34 the rest are just warnings Oct 02 10:38:08 XorA: nothing beats the size of klibc-statical Oct 02 10:38:28 03Henning Heinold  07org.openembedded.dev * r6856ab2772 10openembedded.git/ (4 files in 2 dirs): Oct 02 10:38:28 fastjar: update to 0.98 Oct 02 10:38:28 * switch to INC_PR and .inc Oct 02 10:38:38 03Henning Heinold  07org.openembedded.dev * r664d945001 10openembedded.git/recipes/xorg-proto/ (19 files): Oct 02 10:38:38 xorg-proto: let native packages depend on util-macros-native Oct 02 10:38:38 * adding xorg-proto-native.inc Oct 02 10:38:38 * set DEPENDS and inherit native in it Oct 02 10:38:39 * no version bump is needed Oct 02 10:39:15 woglinde: Jalimo cleanups? Oct 02 10:39:29 ant_work: I don't think there's much point talking about this klibc thing until you can show us what actually goes wrong. It's probably a waste of time for us to just speculate about what the problem might be. Oct 02 10:39:29 hrw yeah we are working on it Oct 02 10:39:46 pb__: yea, sorry Oct 02 10:39:46 but we have some problems with icedtead-1.6.1-native Oct 02 10:39:57 fucking arch-handle in it Oct 02 10:40:09 I'm wining in the hope someone give a look and discover some atrocious bug... Oct 02 10:40:17 especially in hotspot Oct 02 10:40:31 you have to deal on x86 with i368,i468,i568 Oct 02 10:40:39 ant_work: we have discovered an atrocious but, klibc is unmaintained and crap Oct 02 10:40:59 XorA: perhaps at 99% Oct 02 10:41:02 ant I will update dietlibc Oct 02 10:41:16 maybee more stuff is compilable with the new version Oct 02 10:41:23 woglinde: with 2.6.30 kernels we'll have less size for the initramfs. Oct 02 10:41:39 I don't see alternatives for kernel+initramfs in 1,2 mb Oct 02 10:41:52 (see kernel bloat) Oct 02 10:42:07 and well, is already there :) Oct 02 10:42:12 ant_work: then you basically become the klibc maintainer Oct 02 10:42:28 is way beyond my skills Oct 02 10:42:43 ant_work its possible with dietlibc Oct 02 10:42:58 gcc: /home/graeme/bin-i386/start.o: No such file or directory Oct 02 10:43:07 looks like dietlibs expects always i386 Oct 02 10:43:28 xora nope Oct 02 10:43:29 * ant_work hides and goes for a snack Oct 02 10:43:41 you have to inherit dietlibc class Oct 02 10:44:09 sorry there is no other way for now Oct 02 10:44:31 woglinde: should make the recipe fail without class then Oct 02 10:45:10 --disbale-shared Oct 02 10:45:17 dietlibc.bbclass looks broken :-) Oct 02 10:45:25 oh Oct 02 10:45:29 typo Oct 02 10:45:31 hm Oct 02 10:45:40 will clean up Oct 02 10:46:00 woglinde: no hassles, just jumped out at me, I like disbaling :-) Oct 02 10:46:24 yeah I make this typo often Oct 02 10:46:28 too often Oct 02 10:46:39 post commit hook :-) Oct 02 10:46:55 s/disbal/disabl/g :-) Oct 02 10:51:35 03Koen Kooi  07org.openembedded.dev * rfb82cf69a9 10openembedded.git/ (conf/checksums.ini recipes/nautilus/nautilus_2.28.0.bb): nautilus: update to 2.28 Oct 02 11:04:40 k guys i fixed the colour mapping now in the kernel .. fbv can display a image correclty but as soon aas i start a gtk app it crashes on libXrender Oct 02 11:21:37 03Thomas Zimmermann  07shr/import * rf406744ef7 10openembedded.git/recipes/vala/ (vala-native_0.7.7.bb vala_0.7.7.bb): Oct 02 11:21:37 vala: fix SRC_URI for vala-0.7.7 Oct 02 11:21:37 Signed-off-by: Klaus Kurzmann Oct 02 11:29:25 ah, imagemagick seems to be behaving a bit better today Oct 02 11:29:36 memory usage apparently stable at about 6.6GB, not quite as bad as it was last night. Oct 02 11:30:00 * pb__ adds more swap space and goes to find lunch Oct 02 11:30:05 pb can you please notice size L oedem tshirt for me? Oct 02 11:30:40 woglinde: ok, noted Oct 02 11:30:48 so far you are the first person to ask for one :-} Oct 02 11:30:50 thank you Oct 02 11:31:00 hm oh mabyee the other didnt notice it Oct 02 11:31:10 unless we can get some more orders I don't think it is going to be economical to have them printed, the setup charges will be too much for just a couple of shirts. Oct 02 11:31:15 maybee you should write an email to -dev again about it Oct 02 11:31:26 I think we need about 10-15 or so to make it worthwhile. Oct 02 11:31:34 ok, yeah, that's not a bad idea. Oct 02 11:31:39 I should send a reminder about the agenda as well Oct 02 11:33:08 he zecke Oct 02 11:33:30 yo zecke Oct 02 11:36:59 hey Oct 02 11:37:23 pb__: in all your GNU wisdom... have you used libmemusage.so? and how to get patches included? Oct 02 11:37:37 pb__: e.g. there must be a secret cult to get things accepted Oct 02 11:39:51 zecke: I have used it occasionally, though not much. Oct 02 11:39:57 what is the patch you are trying to have included? Oct 02 11:40:50 pb__: bfd alloca with malloc replacement for gdb Oct 02 11:41:36 ah right. did you submit it in bugzilla or something? Oct 02 11:41:49 pb__: somehow my bug report + has been seen, and now someone else wants the binaries and redo the patch :) Oct 02 11:42:07 which is a bit unusual Oct 02 11:42:28 heh. that is a bit weird. who is the "someone else"? Oct 02 11:43:18 pb__: someone that has probably signed the copyright assignment, and has done other alloca -> malloc patches :) Oct 02 11:43:51 ah, yes, you will need to have a copyright assignment Oct 02 11:44:05 if you don't have that then you have no hope of getting patches applied Oct 02 11:44:36 pb__: yes, but what is the procedure with it? I would expect the patch to be reviewed and then asked for copyright assignment Oct 02 11:45:07 it can happen either way around. Oct 02 11:45:27 sometimes the maintainers will not want to even look at a patch without a copyright assignment for fear of having their brains contaminated Oct 02 11:46:21 pb__: do you get a @gnu.org address if you have signed the assignment or how does a maintainer find out? GNU projects really have some weird closed circle of contributors :( Oct 02 11:47:52 zecke: there is a file somewhere on one of the gnu.org machines which contains a list of everyone who has signed a copyright assignment Oct 02 11:48:03 pb__: XL for me would be good Oct 02 11:48:05 I used to have access to it, and technically I think I probably still do, but I can't remember where it is kept Oct 02 11:48:05 Can I copy over the entire OE directory on another system to make it work ? recipes, bitbake and tmpdir - everything included ? Oct 02 11:48:22 rkirti: if the other system is identical, and you put it in the same place, yes. Oct 02 11:48:24 otherwise, probably no Oct 02 11:48:49 We are having a OE introductory session here and the idea is to setup a working oe tree on all machines. Oct 02 11:48:55 pb__: great, http://sources.redhat.com/bugzilla/show_bug.cgi?id=10717 this is my current attempt ti get a patch into glibc Oct 02 11:48:56 pb__: identical in what senses ? Oct 02 11:49:28 rkirti: same architecture, same distro, same approximate filesystem layout Oct 02 11:49:58 pb__: ok. Oct 02 11:50:42 lunchtime now, really Oct 02 11:50:44 * pb__ -> Oct 02 11:54:24 pb__: enjoy Oct 02 11:55:28 warum testet fefe seinen scheiss nicht ccache Oct 02 11:55:37 args Oct 02 11:55:38 sorry Oct 02 11:56:55 woglinde: he is too rich to always have the fastest CPU :) Oct 02 11:57:55 zecke I already did a patch for dietlibc Oct 02 11:58:06 but there are some changes Oct 02 12:07:57 woglinde: btw the issues I had time ago were not originated by ccache Oct 02 12:08:19 ccache works flawlessy on gentoo 32b buildhost Oct 02 12:08:56 03Frederik Sdun  07shr/import * r9dc1b738d8 10openembedded.git/recipes/vala/files/0010-D-Bus-Fix-marshalling-of-GLib.Value-parameters.patch: Oct 02 12:08:56 Add missing patch for vala-0.7.7 Oct 02 12:08:56 Signed-off-by: Frederik 'playya' Sdun Oct 02 12:08:56 Signed-off-by: Klaus Kurzmann Oct 02 12:08:57 03Klaus Kurzmann  07shr/import * r6167876757 10openembedded.git/recipes/vala/ (vala-native_0.7.7.bb vala_0.7.7.bb): Oct 02 12:09:01 vala(-native): enable the fix marshaling patch Oct 02 12:09:03 Signed-off-by: Klaus Kurzmann Oct 02 12:09:05 03Thomas Zimmermann  07shr/import * r159f9b4916 10openembedded.git/recipes/vala/ (vala-native_0.7.7.bb vala_0.7.7.bb): Oct 02 12:09:08 vala: remove gnome_verdir from SRC_URI Oct 02 12:09:10 Signed-off-by: Klaus Kurzmann Oct 02 12:18:41 hi Oct 02 12:18:46 anyone here? Oct 02 12:29:51 no Oct 02 12:30:25 woglinde: will you be around late afternoon? Oct 02 12:31:30 ant hm Oct 02 12:31:33 dont know yet Oct 02 12:31:39 np. I'd like to show you the fresh build-failure Oct 02 12:31:59 I'll be back in a couple of hours @home Oct 02 12:32:01 bbl Oct 02 12:45:36 hurray Oct 02 12:45:42 dietlibc is building again Oct 02 13:00:17 03Koen Kooi  07org.openembedded.dev * r80891610ea 10openembedded.git/recipes/networkmanager/ (4 files in 2 dirs): network manager: work around some dbus at_console problems Oct 02 13:06:42 99 Oct 02 13:19:51 hm, get some glibc warnings, no idea if they are crucial; http://www.pastebin.ca/1589449 Oct 02 14:04:03 eFfeM: those are harmless, you can ignore them Oct 02 14:15:34 gm Oct 02 14:18:13 gm, and gn Oct 02 14:21:10 pb_, remeber my colour issue 2 days ago .. so what if : the kernel logo penguin is good, xsetroot show wrong colours and also does gtk+ and fbv ? Oct 02 14:25:51 pb_ thanks Oct 02 14:29:26 re Oct 02 14:34:59 rob_w: it does rather sound as if the kernel is mis-reporting the pixel format to userspace. Oct 02 14:35:21 right Oct 02 14:35:22 probably the easiest way to settle this for sure is to write a little test program to mmap /dev/fb0 and write to it directly, then see whether your results match what the kernel is telling you. Oct 02 14:35:26 gotcha Oct 02 14:36:01 so, for example, map the framebuffer, fill it with 0x001f, and see what colour you get. Oct 02 14:36:24 then try again with 0xf800 and, again, note the colour. Oct 02 14:59:58 morning Oct 02 15:03:47 03Koen Kooi  07org.openembedded.dev * r86e8a48d0a 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: angstrom: move to a more recent glib-2.0 Oct 02 15:03:58 03Koen Kooi  07org.openembedded.dev * r77e13af5e3 10openembedded.git/ (7 files in 3 dirs): glib-2.0: update to 2.22.1 Oct 02 15:18:38 03Klaus Kurzmann  07shr/import * rb51c0db40b 10openembedded.git/conf/distro/include/shr-autorev-unstable.inc: Oct 02 15:18:38 shr-autorev-unstable: set libgee to AUTOREV Oct 02 15:18:38 Signed-off-by: Klaus Kurzmann Oct 02 15:18:39 03Klaus Kurzmann  07shr/import * rb73a1a4ecc 10openembedded.git/recipes/libgee/libgee_git.bb: Oct 02 15:18:40 libgee_git: adjust PV Oct 02 15:18:42 Signed-off-by: Klaus Kurzmann Oct 02 15:21:32 re Oct 02 15:50:35 florian: wb Oct 02 15:52:22 ~lart debian initramfs Oct 02 15:52:22 * ibot grabs a large, mis-shapened log, with squirrels, and beats debian initramfs until only the nuts remain ... which the squirrels run off with Oct 02 15:52:39 he Oct 02 15:52:54 woglinde: geht-es jetzt? Oct 02 15:53:43 ant yes Oct 02 15:53:56 I had to switch the not documentes RESUME Oct 02 15:53:59 option Oct 02 15:54:02 to my lvm stuff Oct 02 15:54:06 *sigh* Oct 02 15:54:23 pb_: ..so, after monstruous hacks the stopper is Oct 02 15:54:25 | ./purgatory/arch/arm/include/stdint.h:4: error: conflicting types for 'size_t' Oct 02 15:54:26 | /oe/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include/stddef.h:214: error: previous declaration of 'size_t' was here Oct 02 15:54:44 okay Oct 02 15:54:49 --><------>-I$(shell $(CC) -print-file-name=include) Oct 02 15:54:52 probably easiest to just patch out your local definition of size_t Oct 02 15:54:57 this comes in -I Oct 02 15:55:21 size_t isn't something that stdint.h is meant to be defining anyway Oct 02 15:55:43 but with all the pile of -no* ,options, why gcc lib? Oct 02 15:56:58 well, because of the line you just quoted Oct 02 15:57:11 I see now :) Oct 02 15:57:18 "gcc -print-file-name=include" will give you the path to gcc's include directory Oct 02 15:57:25 and, you're taking that and passing it as an -I option Oct 02 15:57:44 yea, it was 'implicit' and I overlooked it Oct 02 15:58:06 you could remove that -I if you want, but I suspect it is probably better to fix your local stdint.h Oct 02 15:58:08 why is purgatory defining its own size_t? Oct 02 15:58:27 quite, that seems like a broken thing to do Oct 02 15:58:29 ehm..not exactly purgatory needing it Oct 02 15:58:50 util_lib/include/sha256.h Oct 02 15:58:53 remove the def Oct 02 15:59:00 let it provide by the normal headers Oct 02 15:59:43 the problem was Oct 02 15:59:45 In file included from purgatory/purgatory.c:5: Oct 02 15:59:45 ./util_lib/include/sha256.h:4:23: error: sys/types.h: No such file or directory Oct 02 16:01:01 I don't quite understand how that relates to what we were just talking about. Oct 02 16:01:10 are you saying that you added the size_t to stdint.h to try to work around the lack of sys/types.h? Oct 02 16:01:41 I commented the //#include Oct 02 16:02:20 let me retry from fresh Oct 02 16:03:55 yes, commenting out the include of sys/types.h is probably the right thing to do Oct 02 16:09:50 well, I thought I removed the gcc lib but is still there... Oct 02 16:10:17 http://fr.pastebin.ca/1589628 Oct 02 16:10:29 I commented out sys/types as you see Oct 02 16:10:49 right Oct 02 16:11:04 so, now delete the bogus size_t from your stdint.h Oct 02 16:11:06 I have to define uintptr_t Oct 02 16:11:17 *sigh* Oct 02 16:11:34 why all this shitty typedefs Oct 02 16:11:40 I will not understand that Oct 02 16:11:48 ant its not against you Oct 02 16:12:06 I did not write the sources ;) Oct 02 16:12:23 yeah but you are now maintainer Oct 02 16:12:27 omg Oct 02 16:12:30 refactor it *g* Oct 02 16:12:42 yeah, uintptr_t should be defined in stdint.h Oct 02 16:13:00 just copy that typedef from the real stdint.h header Oct 02 16:13:16 or refactor Oct 02 16:13:57 http://fr.pastebin.ca/1589631 Oct 02 16:14:00 or that, but I don't think refactoring will provide much relief in the short term Oct 02 16:14:16 I added 16-33 Oct 02 16:14:44 looks fine Oct 02 16:14:51 let's try... Oct 02 16:15:15 I think the WORDSIZE stuff is unnecessary, since both long int and int are 32 bits on a 32-bit host, but that doesn't matter Oct 02 16:16:54 it still errors /oe/build/tmp/cross/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/include/stddef.h:214: error: conflicting types for 'size_t' Oct 02 16:17:07 lol Oct 02 16:17:15 and I removed that -print-file-name=include Oct 02 16:17:23 so, now delete the bogus size_t from your stdint.h Oct 02 16:17:32 did you do that? Oct 02 16:17:38 yes, but why is the gcc lib omnipresent? Oct 02 16:18:07 I don't know without looking at your build system, but the gcc header is the correct one anyway. Oct 02 16:18:25 you should leave that alone and fix your local stdint.h Oct 02 16:19:31 woglinde: if I remove size_t from my stdint Oct 02 16:19:33 | ./util_lib/include/sha256.h:9: error: expected specifier-qualifier-list before 'size_t' Oct 02 16:20:16 add #include to that file Oct 02 16:20:23 or to stdint.h if you prefer, either would be ok Oct 02 16:21:20 pb_ these two headers in purgatory/arch/arm/include (limits.h and stdint.h) were provided by the old arm patches for 1.101 Oct 02 16:21:25 jo kergoth Oct 02 16:21:36 ne whosehey Oct 02 16:21:39 perhaps I should remove them alltogether.. Oct 02 16:21:48 yes Oct 02 16:21:55 they do seem to be more trouble than they are worth Oct 02 16:22:44 then it remains to see if the system headers are found... Oct 02 16:22:47 if you have another suitable stdint.h on hand then you might be better off using that one Oct 02 16:23:00 I would use the klibc ones Oct 02 16:23:13 on the other hand, this latest error is not due to those headers anyway, sha256.h is just broken Oct 02 16:23:19 ah Oct 02 16:24:06 size_t is defined in stddef.h. if sha256.h wants to use that type, it should include that header. Oct 02 16:24:44 from what I see, the headers are badly mixing together..dunno why so many " .h" instead of <.h> Oct 02 16:25:14 remember the recipe is static Oct 02 16:25:29 that doesn't matter for stddef.h Oct 02 16:27:35 anyone seen a build machine's ld say -pie is an unsupported option? Oct 02 16:27:38 hmm Oct 02 16:28:05 particularly odd since its in the man page on this same machine.. Oct 02 16:28:14 haven't seen that, but -pie is a fairly new option Oct 02 16:28:26 this is debian unstable :\ Oct 02 16:28:36 if that has too old a binutils, i'd be very surprised Oct 02 16:28:45 * kergoth grumbles Oct 02 16:28:59 * kergoth fires off a debootstrap to build a testing or stable chroot to try in.. Oct 02 16:29:20 jo thesing Oct 02 16:29:41 what does 'ld --version' say? Oct 02 16:29:49 morning all Oct 02 16:30:08 2.19.91 Oct 02 16:30:17 thesing: hi Oct 02 16:30:17 x86_64 machine, if that matters Oct 02 16:30:26 * kergoth wonders why libtool is even using -pie Oct 02 16:31:12 dbus-native is failing to build with that ld unknown option error on this debian sid box Oct 02 16:31:16 fun stuff Oct 02 16:32:01 kergoth I had fun too Oct 02 16:32:12 with initramfs and RESUME option Oct 02 16:33:17 pb_: adding the include I passed th eerror Oct 02 16:33:28 now strangely klcc strikes back Oct 02 16:33:39 | arm-angstrom-linux-gnueabi-klcc -Wl,--no-undefined -nostartfiles -nostdlib -nodefaultlibs -e purgatory_start -r -o purgatory/purgatory.ro purgatory/purgatory.o purgatory/printf.o purgatory/string.o purgatory/sha256.o Oct 02 16:33:39 | /oe/build/tmp/cross/armv5te/bin/arm-angstrom-linux-gnueabi-klcc: unknown option: -nostartfiles Oct 02 16:33:55 and all following options Oct 02 16:35:26 at the beginning it was failing on --no-undefined, adding -Wl, solved Oct 02 16:36:39 another -Wl Oct 02 16:36:42 let me see Oct 02 16:37:27 hm no isnt a linker option Oct 02 16:44:16 woglinde: I have sshd .... Oct 02 16:44:45 would be easier to see my mistakes :) Oct 02 16:45:42 ant__: I guess you want to use plain gcc, not klcc Oct 02 16:45:57 if you aren't using klibc's libraries to link with then klcc wouldn't bring you any benefit Oct 02 16:46:10 I'm trying to split the compiler and linker options Oct 02 16:46:40 the Makefile vastly changed Oct 02 16:46:46 in better? Oct 02 16:46:56 who knows Oct 02 16:46:59 I can't judge :) Oct 02 16:47:26 pb: we need the smallest kexec binary Oct 02 16:47:31 bye Oct 02 16:51:19 ant__: if you really need the smallest, it is tempting to say you should just ditch all this kexec-tools and klibc nonsense and write something from scratch. Oct 02 16:51:27 kexec is a pretty simple tool, it doesn't do much Oct 02 16:51:34 or even use dietlibc Oct 02 16:52:13 thesing: what do you think? Oct 02 16:52:49 thesing wrote the initial kexecboot binary Oct 02 16:52:58 which relies on kexec Oct 02 16:53:33 woglinde: or that, though diet-libc won't help with kexec-tools itself Oct 02 16:53:53 I'm not sure that diet-libc would be noticeably better than uclibc or even glibc if you had a better program to start with Oct 02 16:54:23 hm busybox? Oct 02 16:54:31 minimal Oct 02 16:54:35 not enough mtd size...1,2 mb Oct 02 16:55:12 no space for busybox Oct 02 16:55:14 03Koen Kooi  07org.openembedded.dev * r37c479af56 10openembedded.git/recipes/networkmanager/ (7 files in 3 dirs): networkmanager: add git bits for nm and nm-applet Oct 02 16:55:39 busybox would be a very bloated way of doing kexec if that's all you want Oct 02 16:56:43 pb_: the cpio.gz is 84 kb Oct 02 16:56:49 nothing competes Oct 02 16:56:50 ant__ how big can the initramfs grow? Oct 02 16:56:55 which tools you need? Oct 02 16:57:00 kernel + initramfs < 1.2 mb Oct 02 16:57:08 thats not the question Oct 02 16:57:16 kernel with minimal config Oct 02 16:58:47 ant__: it should be possible to implement kexec in about 800 bytes I would have thought. Oct 02 16:59:24 so you would still have 83.2k left for your other bloat :-} Oct 02 17:01:28 pb for diet libc I need to be set diet in front of CC, whats the best was to do it in a class? Oct 02 17:03:06 pb_: the kexec tool is pretty big. But I didn't research what it does in detail. Oct 02 17:03:14 er, why are you trying to do that as a class? libc selection is traditionally more of a distro thing Oct 02 17:03:29 thesing: yah, I think 99% of it is probably garbage Oct 02 17:03:34 pb you cant compile many packages with it Oct 02 17:03:54 so for small initramfs its better the other round and have dietlibc packages Oct 02 17:04:02 iirc, it basically just needs to open() and mmap() the kernel, then parse the headers and call kexec(). Oct 02 17:04:46 three syscalls and a little loop. how hard can that be? Oct 02 17:05:39 I didn't look into the actual mechanism on the userspace side. Oct 02 17:06:45 sorry, afk Oct 02 17:07:52 diner now Oct 02 17:07:54 till later Oct 02 17:16:34 i asked this a while ago, but the release of openssh 5.3 has made me think of it again: is anyone successfully getting wtmp logging w/uclibc (libutil)? w/out calling tinylogin Oct 02 17:18:49 might be better to ask the mailing list. I think wtmp is a bit of a fringe interest. Oct 02 17:19:32 'last' is included in the default busybox config Oct 02 17:20:23 calling tinylogin will log to wtmp, but it breaks privsep Oct 02 18:20:02 then recipes that support it could easily toggle it based on the distro policy Oct 02 18:31:04 ah good, my beagleboard has shipped at last Oct 02 18:31:09 silly digi-key Oct 02 18:32:10 gm folks Oct 02 18:34:24 beagleboard eh, nice Oct 02 18:34:37 * kergoth should really pick up more hardware to play with one of these days, getting rusty Oct 02 18:35:10 * kergoth adds to his list of stuff to get in the next 6 months Oct 02 18:37:20 yeah, it seems like a nice unit. Oct 02 18:37:52 apparently it's export-restricted from the usa though, doh. digi-key seemed to have me on some kind of blacklist as a potential foreign military power. Oct 02 18:38:00 huh, that's weird. Oct 02 18:38:38 it is a bit. maybe the omap contains a special undocumented uranium-enriching unit or something. Oct 02 18:39:11 more likely crypto, but uranium-enriching is a lot more exciting :D Oct 02 18:39:17 anyway, I doubt that arizona counts as "foreign" for their purposes, so you ought to be ok Oct 02 18:39:18 The untimely demise of the fd.o homedirs has had a negative effect on shared-mime-info Oct 02 18:40:05 doh. I can't believe fd.o didn't have any backups at all of their homedirs. Oct 02 18:47:42 hi all. i'm trying to figure out why a shared library i'm building seems to work when hand compiled, but not when it's built by bitbake. it's my own custom library and recipe... i'm just asking about some tools to inspect and determine the problem with the library... any good gcc tools ? i'm not a gcc wiz Oct 02 18:48:12 jconnolly: you'll need to elaborate on what you mean by the library not working Oct 02 18:49:06 okay, i need to find and fix hardcoded staging path refs in the scripts in staging. i'm experimenting with lvm snapshots as build areas, so my snap inherits a completely built tmpdir from a base project, but then tmpdir is in a different location :) Oct 02 18:50:31 kergoth: i get load/runtime problems: /usr/lib/jni/libavetanabtcldc.so: undefined symbol: hci_open_dev Oct 02 18:54:18 i thought it was a problem with stripping the lib... after it's stripped it's significantly smaller, but I added INHIBIT_PACKAGE_STRIP=1, which in turn makes the lib the same size as hand-compiled, but it still gives load errors Oct 02 18:58:49 re Oct 02 18:59:24 pb *g* Oct 02 18:59:40 hi khem Oct 02 19:05:31 jconnolly: huh, interesting. what buildsystem does it use? Oct 02 19:06:11 x86_64, target = armv6 Oct 02 19:06:52 recipe calls oe_runmake, when I hand compile it I just set some paths http://pastebin.com/m6b6975af and make all Oct 02 19:07:41 makefile: http://svn.buglabs.net/svn/!source/9969/bug/branches/R1.4/qa/com.buglabs.bug.jni.bluetooth/src/c/Makefile Oct 02 19:08:44 recipe: http://svn.buglabs.net/svn/!source/9969/bug/branches/R1.4/qa/com.buglabs.build.oe/meta-bug/packages/bug-osgi/com.buglabs.bug.jni.bluetooth.bb and inherited class jni-library.bbclass http://svn.buglabs.net/svn/!source/9969/bug/branches/R1.4/qa/com.buglabs.build.oe/meta-bug/classes/jni-library.bbclass Oct 02 19:08:51 this has been killing me for a few weeks now Oct 02 19:09:47 one week? Oct 02 19:11:22 jconnolly type ldd /usr/lib/jni/libavetanabtcldc.so Oct 02 19:12:23 what OE recipe builds ldd? Oct 02 19:12:30 glibc Oct 02 19:38:23 jconnolly hm I think the problem is that libavetanabtcldc.so doesnt finds libbluethooth Oct 02 19:38:39 jni is not that best in this case Oct 02 19:38:52 i thought so too woglinde but when I literally swap just the .so's, it works/doesn't work Oct 02 19:39:01 no export LD_LIBARY_PATH etc Oct 02 19:39:27 could copy libluethooth into the dir of libavetanabtcldc.so Oct 02 19:39:32 and try again? Oct 02 19:39:58 libluethooth should end with .so.2 or so Oct 02 19:41:02 oh even fdo was down xserver 1.7.0 is released Oct 02 19:41:32 jconnolly: it sounds like your LD_FLAGS are not being respected during your final link. hard to say exactly why that is from looking at the files, there doesn't seem to be anything obviously wrong there. I think you'd need to check the logs, and/or poke at the output of "bitbake -e" a bit. Oct 02 19:42:09 pb did you try new eclipse? Oct 02 19:42:22 no, not yet Oct 02 19:42:25 pb_: good idea, i'll look into the environment, but I've been gvimdiff-ing the log's and my hand-compiled output and it looks like the LD_FLAGS are ok Oct 02 19:42:34 woglinde: I have ordered an extra 8GB of RAM though Oct 02 19:42:44 hah Oct 02 19:42:55 jconnolly: what does the final link command look like in the broken case? Oct 02 19:42:57 i like how "new eclipse" necessitates the talk about RAM Oct 02 19:43:12 well, woglinde recommended the new eclipse because apparently it uses less ram than the old one Oct 02 19:43:13 pb_: one sec, I'll pastebin the log Oct 02 19:43:15 pb lol Oct 02 19:43:16 pb_: heh I have 12G for eclipse and vmware Oct 02 19:43:37 lrg__: heh, right. I only have 5GB in my machine at the moment, it's hopeless. Oct 02 19:43:51 lrg I have 4 for eclipse and virtualbox and compiling oe Oct 02 19:44:57 are you on amd64? I wonder if that makes it worse. Oct 02 19:46:41 seems hard to believe now that we used to have a hard limit of 3GB virtual space for each process, heh Oct 02 19:47:18 thats not funny Oct 02 19:49:06 pb_: http://pastebin.com/m854cabc Oct 02 19:49:10 oohhh you maybe be right Oct 02 19:49:21 arm-poky-linux-gnueabi-g++ -march=armv6j -mtune=arm1136jf-s -mfloat-abi=softfp -mfpu=vfp -mthumb-interwork -mno-thumb -B -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -fpermissive -fvisibility-inlines-hidden BlueZ.o -L -lbluetooth -o libavetanabtcldc.so -shared -Wl,-O1 Oct 02 19:49:30 -L is blank Oct 02 19:49:51 my hand-compile logs: Oct 02 19:50:19 right, that blank -L is no good Oct 02 19:50:33 the blank -B looks a bit suspicious as well, though maybe that is correct Oct 02 19:51:02 http://pastebin.com/m796dc720 Oct 02 19:51:09 yeah, definite diff there Oct 02 19:51:38 right Oct 02 19:51:50 I suspect if you fix that -L path then the situation will improve. Oct 02 19:52:09 if not, the next place to look would be to run "readelf -a" on the two .so files and compare the output Oct 02 19:52:17 pb hm why? Oct 02 19:52:34 I thought -L is only for compiletime Oct 02 19:52:42 and dont sets any RPATH Oct 02 19:52:43 no, -L is for linking Oct 02 19:52:51 aeh right Oct 02 19:52:54 sorry Oct 02 19:52:58 yes linking Oct 02 19:53:10 a is for apple, b is for banana, l is for linking Oct 02 19:53:15 didn't they teach you that at school? Oct 02 19:53:22 heh Oct 02 19:53:29 pb he sorry I know that Oct 02 20:04:09 hi effem Oct 02 20:07:43 hey woglinde Oct 02 20:10:00 back Oct 02 20:10:04 re ant Oct 02 20:15:39 woglinde: have you had the chance to look at purgatory's Makefile? Oct 02 20:15:57 ant pastebin it again Oct 02 20:16:08 plain or patched? Oct 02 20:17:02 patched Oct 02 20:17:58 http://fr.pastebin.ca/1589855 Oct 02 20:18:07 I added -nostdinc Oct 02 20:19:17 and -Wl, before --no-undefined Oct 02 20:19:55 I think (khem suggestion) all should be split btw CC and LD Oct 02 20:20:12 yes Oct 02 20:20:15 why not Oct 02 20:21:19 as outlined here Oct 02 20:21:21 http://tinyurl.com/y9fknry Oct 02 20:21:22 $(PURGATORY): CC=$(TARGET_CC) Oct 02 20:21:26 why this? Oct 02 20:21:37 CC=$(TARGET_CC) should be enough Oct 02 20:21:56 other vars too Oct 02 20:22:11 the : defines a make target Oct 02 20:22:47 all after : are deps which must be fullfilled before target can be executed Oct 02 20:23:20 hm Oct 02 20:24:43 actual problem is | /oe/build/tmp/cross/armv5te/bin/arm-angstrom-linux-gnueabi-klcc: unknown option: -nostartfiles Oct 02 20:24:56 if I comment out the options line I get Oct 02 20:25:06 | /oe/build/tmp/staging/armv5te-angstrom-linux-gnueabi/lib/klibc/lib/libc.a(__static_init.o): In function `__libc_init': Oct 02 20:25:06 | __static_init.c:(.text+0x78): undefined reference to `main' Oct 02 20:25:39 I really need nostdlib -nodefaultlibs Oct 02 20:28:39 nostartfiles ist not an linker option Oct 02 20:28:50 hm Oct 02 20:28:51 mom Oct 02 20:30:07 you dont need nostartfiles Oct 02 20:30:15 Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used. Oct 02 20:30:30 because you are setting nodefaultlibs nostdlibs Oct 02 20:30:36 the option is obsolete Oct 02 20:30:48 thats how I read it Oct 02 20:31:21 ok, then the others too ..nux-gnueabi-klcc: unknown option: --no-undefined Oct 02 20:31:45 ..nux-gnueabi-klcc: unknown option: --no-undefined Oct 02 20:31:50 oops Oct 02 20:32:21 ..nux-gnueabi-klcc: unknown option: --no-undefined Oct 02 20:32:27 ..nux-gnueabi-klcc: unknown option: --no-stdlib Oct 02 20:32:36 argh...pastebin... Oct 02 20:32:41 seems klcc is dumb Oct 02 20:32:47 use gcc for linking Oct 02 20:33:06 you see, they have a $(LD) line (commented out) Oct 02 20:33:13 in the Makefile Oct 02 20:34:33 what is the content of klcc Oct 02 20:36:35 its only a perl script Oct 02 20:37:11 * XorA|gone is actually stunned by what was just posted on oe-devel Oct 02 20:37:21 xora hm let me see Oct 02 20:37:36 woglinde: how to install a package the really hard way Oct 02 20:38:50 woglinde: doh.. Oct 02 20:38:51 arm-angstrom-linux-gnueabi-klcc -Wl,--no-undefined -e purgatory_start -r -o purgatory/purgatory.ro purgatory/purgatory.o purgatory/printf.o purgatory/string.o purgatory/sha256.o Oct 02 20:38:51 | /oe/build/tmp/cross/armv5te/bin/arm-angstrom-linux-gnueabi-klcc: unknown option: -e Oct 02 20:39:45 lol Oct 02 20:40:21 the post Oct 02 20:40:21 on oe-dev Oct 02 20:40:25 but he asked earlier here Oct 02 20:40:44 I'm losing any hope..let just see how the old recipe was compiled... Oct 02 20:40:59 but I thought I need some ugly thinks to do before making the image Oct 02 20:41:04 args he Oct 02 20:41:22 ant__: as woglinde said (and as I also mentioned to you about three hours ago) you should just use plain gcc for your final link step, forget about klcc. Oct 02 20:41:52 pb here is the root of klcc Oct 02 20:41:54 http://git.kernel.org/?p=libs/klibc/klibc.git;a=tree;f=klcc;h=f916d25fe5c99ecc62818756263a0c3787b918fa;hb=HEAD Oct 02 20:45:32 03Klaus Kurzmann  07shr/import * r307b4dbf40 10openembedded.git/conf/distro/include/shr-autorev-unstable.inc: Oct 02 20:45:32 shr-autorev-unstable: set cornucopia back to AUTOREV for vala 0.7.7 Oct 02 20:45:32 Signed-off-by: Klaus Kurzmann Oct 02 20:45:36 btw I'd rename this purgatory file...seems hell would be more appropriate... Oct 02 20:45:41 03Klaus Kurzmann  07shr/import * rcf83ab7be4 10openembedded.git/recipes/tangogps/ (tangogps-0.9.7/maptile-zoom-fix.patch tangogps_0.9.7.bb): Oct 02 20:45:41 tangogps: add patch for zoom segfault Oct 02 20:45:41 Signed-off-by: Klaus Kurzmann Oct 02 21:17:32 woglinde: using LD seems going further...now I stop kexec.c:942: undefined reference to `fscanf' kexec.c:998: undefined reference to `getline' Oct 02 21:17:47 isn't getline in stdio.h ? Oct 02 21:34:26 Hi Oct 02 21:34:43 while building oe, I got ERROR:function do_compile failed... /usr/local/ld: cannot find -lts | collect2 ld returned 1 exit status Oct 02 21:45:02 ant__: the prototype is in stdio.h, but the actual function is in libc. if you are linking with -nostdlib then this function will not be available to you. Oct 02 21:45:48 pb_: thx. really bad luck... Oct 02 21:47:48 ant__: I start thinking that reimplement kexec inside kexecboot may be simplier way :) Oct 02 21:48:09 he Oct 02 21:49:18 seems you have already rewritten half of code :) Oct 02 21:51:07 jay7 *g* pb told him the same Oct 02 21:51:34 I should look into kexec tools.. Oct 02 21:51:36 Vink you are missing tslib somewhere Oct 02 21:51:43 may be tomorrow Oct 02 21:52:48 hm klibc and kexectools are maintained Oct 02 21:52:59 atleast what I saw an kernel.org Oct 02 21:53:17 I don't know if I should commit the 'progresses' or not :) Oct 02 21:53:55 ant you are using git stuff on both? Oct 02 21:53:59 aeh from Oct 02 21:54:17 no, the recipes in OE Oct 02 21:54:25 args Oct 02 21:54:26 last 'stable' Oct 02 21:54:37 why didnt you look up at newer stuff Oct 02 21:54:40 maybe its fixed Oct 02 21:54:45 no big improvements Oct 02 21:54:54 I'v elooked at it Oct 02 21:55:03 arm was totally unrecognized :) Oct 02 21:55:13 little bug Oct 02 21:55:38 well, kexec-tools 2.x is compiling ok against glibc Oct 02 21:55:52 yea Oct 02 21:55:57 but we have problems with static linking against klibc Oct 02 21:56:06 not sure about shared linking Oct 02 21:56:29 ant commit it Oct 02 21:56:35 whith -1 Oct 02 21:56:48 is already there Oct 02 21:56:56 I'll update the patch Oct 02 21:57:08 maybe you should forget klibc and focus on trying to get an acceptable binary size by static linking with uclibc. Oct 02 21:57:44 or, yeah, just forget about kexec-tools altogether and implement a new kexec equivalent from scratch. Oct 02 21:57:44 or dietlibc Oct 02 21:57:49 pb_: I think you and woglinde leaded me almost there Oct 02 21:58:17 there = klibc-static Oct 02 21:58:30 yeah, or dietlibc, though I don't quite understand what advantages it has over uclibc. Oct 02 21:58:42 smaller Oct 02 21:59:01 I'll look to kexec syscall manual and kexec-tools code Oct 02 21:59:10 then we will decide :) Oct 02 21:59:12 how much smaller? Oct 02 21:59:27 pb didnt try jet Oct 02 21:59:37 but maybee kexec-tools is good candidate to test Oct 02 21:59:45 may be it's really not so hard Oct 02 22:00:14 yeah, we talked about that earlier Oct 02 22:00:15 iirc, it basically just needs to open() and mmap() the kernel, then parse the headers and call kexec(). Oct 02 22:00:15 three syscalls and a little loop. how hard can that be? Oct 02 22:00:19 btw, then we can implement uImage loading too.. Oct 02 22:00:59 woglinde: thanks... libts was missing Oct 02 22:01:23 Vink put it in the DEPENDS line of the recpie Oct 02 22:01:23 hm.. pb_, when it is as you write then easier is to implement this directly in kexecboot Oct 02 22:02:10 args why needs it perl to compile Oct 02 22:02:13 ah right Oct 02 22:02:14 klcc Oct 02 22:06:55 woglinde: which file? recpie? Oct 02 22:07:29 Vink what ever you are compiling Oct 02 22:07:44 you didnt tell us Oct 02 22:08:06 just running bitbake console-image Oct 02 22:08:42 and which package choked out at the libts error? Oct 02 22:09:57 ant why you need the newer kexectools? Oct 02 22:10:30 libsdl Oct 02 22:10:39 183 of 2238 Oct 02 22:16:05 * Jay7 -> sleep Oct 02 22:24:08 woglinde: it seems the new kernels > 2.6.28 won't work with older Oct 02 22:37:52 woglinde: here we are... Oct 02 22:37:58 git pull --rebase Oct 02 22:38:07 oops Oct 02 22:39:42 03Andrea Adami  07org.openembedded.dev * r56a4dce3e9 10openembedded.git/recipes/kexec/files/ (kexec-tools-2-headers.patch kexec-tools-2-klibc.patch): kexec-tools-klibc-static_2.0.1: rework patches. Still won't build. WIP Oct 02 22:43:03 woglinde: now you can can start laughin Oct 02 22:49:12 hm I found a little error in klibc Oct 02 23:07:30 hm fscanf can be changed to fread and sscanf Oct 02 23:07:48 and getline wasn't used in the old version Oct 02 23:10:03 fgets Oct 02 23:10:18 go! ;) Oct 02 23:32:57 woglinde: btw the old static was not stripped! Oct 02 23:33:08 is a recent fix in OE Oct 02 23:33:09 haha Oct 02 23:33:36 I am trying kexec-tools with dietlibc Oct 02 23:41:40 woglinde: kexec 109k Oct 02 23:42:15 (the old version, kexec: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped) Oct 02 23:48:13 falling on the kb...'nite Oct 02 23:54:55 pb_, woglinde, thanks i think i got it. an extra set of eyes always helps Oct 02 23:55:19 kergoth too, thx Oct 02 23:59:03 Hi, can someone please tell me how to resolve *.ipk dependencies if they're all on my SDcard....currently when I install 1 ipk it says I have to satisfy dependencies.....but all of the dependent *.ipks are on the SDcard Oct 02 23:59:45 I have lotf of ipks to install....so doing one-by-one is not practical. Oct 03 00:05:13 Hi OE experts Oct 03 00:06:16 nhg: if it's only the dependent packages on the SD, just ipkg install *.ipk Oct 03 00:07:11 nhg: what i do locally is just install lighttpd, symlink tmp/deploy/ipk/ with /var/www/repo, and add the url to my ipkg.conf Oct 03 00:07:39 Yes...I'm doing that...but its saying there are other dependencies....but all of them are on the SDcard....how do I tell the package manager "please look in my sdcard for all of the needed ipks"? Oct 03 00:08:29 can you pastebin.com the output of ipkg? Oct 03 00:08:40 and also an ls -haltr *.ipk ? Oct 03 00:09:21 what is /var/www/repo? and can you please copy/paste your contents of ipkg.conf? Oct 03 00:10:20 not infront of my target....but it was looking for "tslib" related ipks Oct 03 00:10:41 I dont have ethernet working Oct 03 00:19:17 but if you tell me how to modify the opgk.conf....it will me some motivation to get ethernet working Oct 03 00:22:45 jconnolly what was the error? **** ENDING LOGGING AT Sat Oct 03 02:59:57 2009