irclog2html for #oe on 20050105

00:02.14*** join/#oe keith_ (~keith@bh02i525f01.au.ibm.com)
00:03.09*** part/#oe jmau (~jmau@pD9E5DADF.dip.t-dialin.net)
00:05.47beewoolieIs there a glibc optimizer stage I can run?  Like the one that debian used (uses?) in the installer.
00:10.17RP"The LZ9JG19 and the LH58123 are exclusive ICs for a limited customer". That's me told then...
00:10.24*** join/#oe Tamath (~tamath@tamath.gotadsl.co.uk)
00:10.41RP(That was the response from Sharp to my request for information)
00:11.36pb_beewoolie: no, but it'd be very cool if you'd like to contribute one.
00:18.41CosmicPenguinthe way this is acting, you would think nobody ever build openldap with gcc 3.4 before
00:18.41beewooliepb_: well, it ought not be hard, but it may be something that has to run when the filesystem itself is built.
00:18.49pb_yeah
00:21.24*** join/#oe dkey| (~dkey@L0003P21.dipool.highway.telekom.at)
00:24.04kergothpb_, beewoolie: glibc optimizer?  what does it do?
00:24.16kergothwent home, no electricity yet
00:24.17pb_kergoth: I think he means mklibs, the library reducer.
00:24.18kergothheh
00:24.20pb_heh
00:24.20kergothah
00:26.24pb_This GDB was configured as "arm-linux"...Segmentation fault
00:26.25pb_root@h3900:~#
00:26.27pb_suck
00:26.37kergothheh
00:26.50kergothi saw that behavior too, makes it not very useful
00:26.51beewooliekergoth: it removes symbols from the libraries that aren't needed by applications.
00:26.52kergoth| ../../../config/./nsinstall -R -m 444 /home/kergoth/code/build-tosa/tmp/work/arm-linux-uclibc/minimo-0.0cvs20050104-r7/mozilla/nsprpub/pr/include/md/ /home/kergoth/code/build-tosa/tmp/work/arm-linux-uclibc/minimo-0.0cvs20050104-r7/build-arm-linux-uclibc/dist/include/nspr
00:26.56kergoth| ../../../config/./nsinstall: cannot make symbolic link /home/kergoth/code/build-tosa/tmp/work/arm-linux-uclibc/minimo-0.0cvs20050104-r7/build-arm-linux-uclibc/dist/include/nspr/md: File exists
00:27.00kergoth| make[6]: *** [export] Error 1
00:27.20kergothheh
00:27.29kergothapplications in general, or the ones currently installed?
00:27.44beewooliebtw: pxa built OK.  Thanks for the help.  I'd be happy to make some edits to the sample conf to make it easier for lunk-heads like me.
00:27.55kergothpatches welcome
00:29.18pb_drat, the gnutls people want me to fill in a copyright assignment for a tiny patch
00:29.59beewooliethe library optimizer reads the dynamic link symbols from so's and executables and removes the unused symbols from the library.  The idea of 'installed' isn't really compatible with this thing.  Obviously, adding a package might be a proble,
00:30.23kergothgotcha
00:30.31kergothso its only really useful for relatively static environments
00:30.35pb_yeah
00:30.42kergoththat's cool though
00:30.42CosmicPenguinStill nice to have
00:30.43beewoolieNot really.
00:30.48kergothfor initrds, or what have you
00:30.56kergothbleh, headache
00:30.59CosmicPenguinwill it remove an entire library if no symbols are used?
00:31.08beewoolieIt turns out that most symbols are used by the applications most people use.
00:31.19beewoolieIt might make the library empty.
00:31.33pb_CosmicPenguin: it will generate a stub .so, otherwise programs that were linked with it wouldn't be loadable.
00:31.39beewoolieIn other words, once it runs, most applications will still run.
00:31.46CosmicPenguinpb_: true...
00:31.57kergoththat's pretty cool.
00:32.08CosmicPenguinpb_: back in the buildroot days I had a perl script that used ld to eliminate unused libraries
00:32.13CosmicPenguinagain, only useful in static envrionments
00:32.23beewoolieIt's handy for getting the bulk out of libc.  ulibc, I believe, is another way to do this.
00:32.29CosmicPenguinbut my primary target right now is static, so i would be very interested in such a beast
00:32.41CosmicPenguinNOTE: package openldap: build completed
00:32.44CosmicPenguinWill wonders never cease
00:32.48kergothheh, cool
00:32.54beewoolieI'd guess that a non-static environment hasplenty of space.
00:33.03kergothbeewoolie: that isnt necessarily the case.
00:33.10pb_CosmicPenguin: it's just a little python script.  you can get it from debian-boot cvs.
00:33.10kergothbeewoolie: pdas like zaurus and ipaq for example
00:33.20pb_might need a bit of tweaking for cross operation, but probably not much.
00:33.27CosmicPenguinWhats it called?
00:33.30pb_mklibs.py
00:33.31keturnI have a static target too, but that sounds scary to me.  I'll have to be pretty pressed for space before I resort to that.
00:33.50*** join/#oe Cwiiis (~cwiiis@user-214-207-151-83.e7even.com)
00:34.17beewoolieI set ASSUMES_PROVIDED=virtual/arm-linux-gcc and I'm still getting a gcc build.  I wonder if this isn't the wrong ASSUMES.
00:34.46kergothbeewoolie: its ASSUME, not ASSUMES.  you're using an external toolchain i presume?
00:34.52beewooliekergoth: well, when space is tight, especially floppy disk sized tight, something as to give.
00:35.35beewoolieRight.  ASSUME.  Yes.  I'd like to use a prebuilt toolchain.  Phil gave me this formulation.
00:35.36CosmicPenguin<PROTECTED>
00:35.37CosmicPenguinnice
00:35.48kergothbeewoolie: yes, i know.  that doesnt have anything to do with your statement that a non-static environment has plenty of space.  pdas generally dont have plenty of space, but do generally allow installing and uninstalling of packages.
00:37.09beewoolieThe standard libc is ginormous.  As we all know.  IIRC, the optimizer game me a couple of hundred K back.  It might even have been more, but I don't recall at the moment.
00:40.35beewooliepb_: I think that I used the py and the shell versions both.  IIRC, there was a reason why I abandoned the python version.  It might have been slower than the shell script.
00:40.56*** join/#oe CoreDump|hom (~mhentges@xdsl-213-196-226-123.netcologne.de)
00:41.23pb_beewoolie: seems unlikely.  the mklibs.sh one was almost always much slower.
00:41.37pb_iirc, speed was the primary advantage of mklibs.py in the first place
00:42.20Tygger-BobChris.. can you do that update thing again? Cwiiis updated matchbox..
00:42.26beewooliepb_: well, it's been at least two years since I used it.  It might have simply been a problem running the python version.
00:42.29kergothTygger-Bob: will do
00:42.38Tygger-Bobplease, btw.. and thank you.
00:42.45kergothneat, real actual traffic on the unionfs mailing list
00:42.51kergothheh
00:43.24beewoolieThe ASSUME_ switch seems to really not have worked.  Anyone used it to coerce the use of another toolchain?
00:43.42kergothyes
00:44.05kergothASSUME_PROVIDED = "virtual/${TARGET_PREFIX}gcc virtual/libc"
00:44.12kergoththat's in my build-omap-exttc/conf/local.conf
00:44.15beewooliekergoth: I've got ASSUME_PROVIDED = "virtual/arm-linux-gcc"
00:44.23kergothwhich is my tree for building packages against an external toolchain for work
00:44.42beewooliekergoth: ah.  Phil's way doesn't work.  Changing it...
00:45.01kergothhaving virtual/arm-linux-gcc should be fine, as long as your TARGET_ARCH is arm and your TARGET_OS is linux
00:45.51kergothit'll build a C library, mine wont
00:45.51kergothbeyond that, either should work
00:45.51beewoolieIsn't linux the default targetOS?
00:45.52kergothtechnically, the default target os is the build os
00:45.55kergothand the default build os is read out of a call to uname
00:46.04kergothso if you're building on cygwin, or a bsd, thatll be your default target as well
00:46.12kergothbut yes, in most cases the default would be linux
00:46.14CIA-1003pb 07 * r1.2865 10openembedded/packages/gpe-aerial/ (files/fix_makefile.patch gpe-aerial_0.2.12.bb): update gpe-aerial to 0.2.12
00:46.39beewooliekergoth: well, your method puts out the same ASSUME_ that mine did, except for the library.
00:46.51kergothright, and i'm saying either shouldve worked
00:46.57beewooliekergoth: right.
00:47.38beewoolieI wonder if this isn't the problem: I've got the PREFERRED_PROVIDERS with " virtual/${TARGET_PREFIX}gcc:gcc-cross"
00:47.53kergothlooks fine.
00:47.57beewooliekergoth: that makes me think it's gonna force the use of gcc-cross
00:48.02kergoth..
00:48.15kergothgcc-cross is one of 3 different packages that PROVIDES virtual/${TARGET_PREFIX}gcc
00:48.26kergothyou're saying that virtual/${TARGET_PREFIX}gcc is already provided, so it doesnt have to build it at all
00:48.28beewoolie...and doesn't it build a compiler?
00:48.31kergothregardless of which provider you prefer.
00:48.43beewooliehmm.  We'll gcc-cross is the package being built.
00:48.45kergothall PREFERRED_PROVIDERS does is gives you a way to exert control over multiple provides situations
00:48.48kergothtahts all
00:48.50kergothof course it is.
00:48.59kergothits trying to build virtual/${TARGET_PREFIX}gcc
00:49.06kergothit should not be if tahts listed in ASSUME_PROVIDED
00:49.17kergothyour preferred providers is just a preference. it isnt forcing anything
00:49.25kergothand it will not subvert what assume_provided does
00:49.33beewoolieI'm assuming that if I say don't build gcc, then it won't build gcc-cross.
00:49.42kergoth?
00:49.46kergothyou arent saying dont build gcc.
00:49.53kergothyou're saying dont build virtual/${TARGET_PREFIX}gcc
00:49.59beewoolieThat's what I mean.
00:50.17kergothif a package in the tree directly depended on gcc-cross, that would be built regardless
00:50.21beewoolieIf I say don't build arm-linux-gcc, then I assume it won't build gcc-cross.
00:50.26kergothbut nothing does. everything depends on virtual/${TARGET_PREFIX}gcc
00:50.30beewoolieWell, that's what may be the case.
00:50.32kergoththat's correct
00:50.35kergothno, that isnt the case.
00:50.39kergothunless you changed something to do so
00:50.42beewoolietee hee.
00:51.01beewoolieis there a command to dump the dependency tree/
00:51.08kergothbitbake --help
00:51.20kergothtry bitbake -v --dry-run [whateveryouwanttobuild]
00:58.27beewooliekergoth: nothing in the dry-run
00:59.20beewoolieHmm. could be g++, though.
01:00.17CosmicPenguinhmmm... I wonder why AC_CHECK_HEADERS is drawing a blank
01:01.31kergothbeewoolie: nope, there's no seperate provider for g++.
01:01.43kergothbeewoolie: run bbread, confirm ASSUME_PROVIDED is set the way it should be
01:02.16beewooliekergoth: did.  ASSUME_PROVIDED is what we expect.
01:03.01pb_beewoolie: what do you mean by 'nothing in the dry-run', exactly?
01:03.24beewoolieNo dependencies listed for gcc-cross.  It is trying to build it, though.
01:04.02pb_I doubt it's just trying to build it completely at random.  What does it say?
01:04.17beewoolieHmm.  It looks like adding an ASSUME field for g++ eliminated the gcc-cross dependency.  I'm going to see what happens when I remove it again.
01:04.59kergothah, there is indeed a virtual/arm-linux-g++ provides, but i didnt think anything depended on ti
01:05.02kergothheh
01:05.05kergothit
01:05.09*** join/#oe darkschneider (~gab@81-208-36-80.fastres.net)
01:05.45beewoolieThis is the first time in a LONG time that I've wanted a faster computer.
01:05.56pb_kergoth: mm.  nothing seems to.
01:05.59Cwiiisbeewoolie: Know how you feel
01:07.55beewoolieGosh darn it.  It isn't doing it now.  
01:08.00kergothhehe
01:08.10beewooliewhatever
01:08.31CosmicPenguin`struct std::ios::seek_dir' has not been declared
01:08.42CosmicPenguinThat has clusterfuck written all over it
01:09.23CosmicPenguinare there any C flags to make G++ 3.4 much less restrictive?
01:10.15beewoolieif the structure hasn't been declared?  Is a forward sufficient?
01:11.45pb_CosmicPenguin: -fpermissive?
01:12.01beewoolieOK.  somethings not right here.  I'm looking that the process table and I'm seeing that a cross compiler from the TMPDIR/cross directory is being run.
01:12.22pb_TMPDIR/cross goes on the front of your $PATH.
01:12.36pb_If there's a compiler in there, it will be the one that gets used.
01:12.50beewoolieBut I told it to clean gcc-cross....
01:13.04pb_That doesn't clean the cross or staging directories.
01:13.13beewoolieIs it safe to remove the cross directory?
01:13.38CosmicPenguinOh, shit - I know why its doing that
01:13.40pb_If you're providing gcc and binutils externally, yeah, I guess so.
01:19.30beewoolieIs the BBFILE_PRIORITY priority higher for higher or lower numbers?  docs don't say.