irclog2html for #uclibc on 20050501

00:00.25mjn3trying again without the 300-120 patch
00:00.52mjn3which i didn't use earlier today
00:02.09mjn3not the only thing i changed.  but i'm thinking it may be the culprit
00:17.35sjhillgo go go
00:18.49anderseemjn3: ok it is official.  The cause of the mysterious gcc 3.3.5 exception handling failure is definately sjlj.
00:19.07mjn3cool.  let's kill it
00:19.18anderseeyup
00:20.11sjhillexcellent, cross and native success for gcc-4.1.0 and binutils-2.16
00:20.19sjhillnow to turn on locale support
00:20.22mjn3cool
00:21.17anderseemjn3: looks like this will do it
00:21.20andersee<PROTECTED>
00:21.20andersee<PROTECTED>
00:21.20andersee-       default "--enable-sjlj-exceptions"
00:21.20andersee+       default "--enable-sjlj-exceptions" if BR2_GCC_VERSION_3_3_3
00:21.20andersee+       default ""
00:22.05CIA-1003landley * r10215 10busybox/ (include/libbb.h libbb/setup_environment.c networking/zcip.c): (log message trimmed)
00:22.05CIA-10On Tuesday 19 April 2005 21:10, Tito wrote and today added:
00:22.05CIA-10> Hi,
00:22.06anderseeIdeally, we would now kill off gcc 3.3.3, but I need to make certain I convince bcom first
00:22.57mjn3hmm... what about even older gcc?  i'd say just turn it off by default and change the comment to say "if using gcc 3.3.3 or older then you may need to set this to <old setting> for c++ exception handling to work"
00:23.50anderseeI dont use it
00:23.57sjhillyay
00:23.59anderseeand I dont support it...
00:24.07anderseeall in favor?
00:24.10sjhillI
00:24.24solar+1
00:24.31anderseeAll opposed?
00:24.34mjn3works for me
00:24.38andersee<sound of crickets chirping>
00:24.44anderseethe ayes have it
00:26.04mjn3heh... i hadn't realized all gcc < 3.3.3 had been removed.  guess i can clean up the soft float stuff in the .mk file then
00:26.32mjn3and get rid of the 3.2.x spec file hackiness
00:34.13CIA-1003andersen * r10216 10buildroot/toolchain/gcc/Config.in: (log message trimmed)
00:34.13CIA-10It is now official, the cause of the mysterious gcc 3.3.5 exception
00:34.13CIA-10handling failure is definately sjlj. Only enable it for the apparently
00:35.56anderseeanyone have any reason to keep gcc 3.3.4, 3.4.0, 3.4.1, and 3.4.2 in buildroot?
00:38.07sjhillmake sure you leave a couple leaves, okay?
00:38.38mjn3as far as i'm concerned, 3.3.4, 3.4.0, and 3.4.1 can go.  i'd be tempted to keep 3.4.2 around a bit longer, just to have a quick check in case we see 3.4.3 doing something weird.  i've done a lot more testing of 3.4.2 than 3.4.3
00:39.30mjn3of course, if got it on my machine here so you killing that too wouldn't be a big problem
00:39.45mjn3s/if got/i've got/
00:40.54mjn3going to weed in binutils too?
00:41.47anderseemjn3: only gcc 3.3.3, 3.3.5, 3.4.2, 3.4.3, 4.0.0 will remain then
00:41.55anderseemjn3: yeah, I think so
00:42.27sjhilland 4.1.0
00:42.28sjhillsheesh
00:42.59mjn3heh
00:43.16CIA-1003andersen * r10217 10buildroot/toolchain/gcc/ (7 files in 5 dirs): Weed out older, no longer maintained versions of gcc
00:43.50anderseesjhill: heh
00:43.59anderseesjhill: yeah, that too
00:44.01andersee:)
00:44.47anderseeany preferences for binutils versions that need to remain
00:45.36anderseeHow about I trim everything but 2.15, 2.15.94.0.2.2, and 2.16*?
00:46.32mjn3sounds good to me
00:46.49mjn3unless you want to also keep the latest 2.14 around
00:46.57anderseeyeah, suppose so
00:47.08anderseesome obscure arch or other may prefer that version
00:47.11mjn3but i have uses anything outside your list in a while
00:49.00anderseemjn3: eh?
00:49.16mjn3your list of proposed binutils versions to kee
00:49.20mjn3keep
00:49.43mjn3was just thinking someone might want to use a 2.14 with gcc 3.3.x
00:51.48anderseethough we never had support for stock 2.14
00:52.31CIA-1003andersen * r10218 10buildroot/toolchain/binutils/ (11 files in 11 dirs):
00:52.31CIA-10Prune out a bunch of binutils versions that are no longer
00:52.31CIA-10the latest and greatest in their respective binutils series
00:53.01solaris sparc on binutils-2.15 yet?
00:54.32solarn/m looks like they work with =binutils-2.15.92.0.2
00:55.13anderseesolar: how about 2.15.94.0.2.2?
00:58.09anderseeguess we can bring it back to life if anybody whines about it
00:58.16mjn3true
01:20.53mjn3sjhill: it looks like that 300-120 patch breaks the libjava build.  i removed it and the build is going fine.  assuming the native build finishes, i'm going to punt it
01:38.51sjhillmjn3: sounds good
01:38.59sjhilli'm getting ready to check in my stuff for 4.1.0
01:39.25sjhilli haven't tested java/objc yet
01:39.48mjn3ok.  i just finished supper and i'm about to start looking for the reason why the libstdc++ config.h is different for cross and native
01:45.41sjhill/home/sjhill/buildroot-gcc4/build_mips/staging_dir/bin-ccache/../lib/gcc/mips-linux-uclibc/4.1.0/../../../../mips-linux-uclibc/sys-include/unistd.h:240: error: two or more data types in declaration specifiers
01:45.46sjhillhmm
01:45.51sjhillthat doesn't look good
01:50.46mjn3doesn't look like any error message i've seen recently
01:51.21sjhillthat was for e2fsprogs
01:51.29sjhilleverything else is building without errors
01:52.00mjn3ah.  i've only been building the toolchain
01:52.28sjhillhmm, that was the only app that failed
01:52.35sjhillit just built the ext2 and cramfs images
01:52.53mjn3well, that and gawk since there's some code in it that triggers a failure if limits.h doesn't get fixed up correctly
01:53.16sjhillhmmm, didn't notice that one
01:53.21sjhilllet me investigate deeper
02:06.49sjhillgawk built
02:06.57sjhille2fsprogs is the only bad one
02:07.14mjn3what's the preprocessed output look like?
02:07.24sjhilli'm still trying to decipher it
02:09.35sjhille2fsprogs, netkit-base (inetd), util-linux (mkfs.minix)
02:09.40sjhillthose are the failures
02:09.49sjhillnetkit and util have errors with lvalue problems
02:22.33mjn3cool.  soft float + locale built
02:22.45sjhillgreat
02:22.56sjhillfixed netkit
02:23.14sjhillgcc-4.x specific
02:23.23sjhill#define SWAP(type, a, b) {type c=(type)a; (type)a=(type)b; (type)b=(type)c;}
02:23.31sjhillreplaced with:
02:23.34sjhill#define SWAP(type, a, b) {type c=(type)a; a=(type)b; b=(type)c;}
02:31.22sjhillessentially any place where there is:
02:31.47sjhill(type)var1=(type)var2;
02:31.56sjhillgcc-4.1.0 does not like
02:32.01sjhilllooks like it became more strict
02:33.35mjn3casting the lhs of an assignment was deprecated in gcc 3.4
02:33.45sjhillwell there you go :)
02:33.53sjhillso, you will hit that with 4.0 i would expect
02:34.03mjn3yep
02:34.13sjhilli'll check in patches to netkit and util-linux in a few minutes
02:34.37sjhillnetkit is a one line change
02:34.40sjhillutil-linux....about 15
02:40.02mjn3hmm... something is hosed with this configure test
02:47.45sjhillwhoo boy
02:48.04sjhillxdr.h is going to need an overhaul
03:12.03mjn3as i recall, it is an ugly mess
03:12.33mjn3perhaps it is already overhauled in glibc
03:22.25CIA-1003mjn3 * r10219 10buildroot/toolchain/binutils/2.16.90.0.2/300-120_mips_xgot_multigot_workaround.patch: No longer needed and actually breaks the gcc java build.
03:31.14*** join/#uclibc quitte_ (~quitte@p54A09154.dip0.t-ipconnect.de)
03:36.44sjhillmjn3: still there?
03:36.58mjn3yeah
03:37.03sjhillcheck me on this
03:37.14sjhill<PROTECTED>
03:37.14sjhill-((long)ntohl((u_long)*(*(u_int32_t**)&(buf))++))
03:37.14sjhill+(long)ntohl((long)*(buf++))
03:37.40sjhilli think those are equivalent without casts
03:37.52sjhill<PROTECTED>
03:37.52sjhill-(*(*(u_int32_t**)&(buf))++ = (long)htonl((u_long)(v)))
03:37.52sjhill+{buf = (long)htonl((u_long)(v)); buf++;}
03:37.56sjhilland that
03:41.22mjn3afraid it isn't equivalent.  what if buf is a char *?  it only increments by one char and not by one long
03:46.05sjhill*sigh*
03:46.18sjhilli'm having a heck of time working around this lhs deprecated crap
03:50.06mjn3yeah.  that xdr code is exceedingly nasty
03:54.19mjn3you might try something like       ((long *) (buf = (void *)( ((char *)buf)+sizeof(long) )) )[-1]
03:55.50mjn3nasty, but i think it is compliant
03:56.08mjn3disclaimer.... untested
04:00.38mjn3back in about 30 minutes
04:12.25SpanKYmjn3: work out hte binutils stuff ?
04:14.19SpanKYah i e-mailed binutils about the tests a day or two ago actually
04:14.36SpanKYi didnt notice the configure.in though ... i'll e-mail about that too
04:26.25sjhillok
04:26.29sjhilli think this correct now
04:26.45sjhill-((long)ntohl((u_long)*(*(u_int32_t**)&(buf))++))
04:26.54sjhill+((long) ntohl(*((u_int32_t*)buf++)))
04:27.16sjhilland
04:27.23mjn3back
04:27.37sjhill-v)))
04:27.39sjhillgah
04:27.48sjhill-(*(*(u_int32_t**)&(buf))++ = (long)htonl((u_long)(v)))
04:28.00sjhill+*((u_int32_t *)buf) = (long)htonl((u_long)v);
04:28.08sjhill+(u_int32_t *)buf++;
04:28.16sjhilli think that takes care of them
04:28.31sjhillmjn3: what's it look like?
04:28.32mjn3SpanKY: just a few fixes.  what's in svn now builds both cross and native for mipsel
04:28.48mjn3gimme a sec.  just walked in the door
04:29.14SpanKYyeah i saw the diffs on the list
04:29.27SpanKYi e-mailed the configure.in change upstream
04:30.25mjn3sjhill: there's still an issue if buff is not a long *.  that's why i went to the trouble of casting to char * and adding sizeof(long).  i don't think you can portably increment a cast pointer
04:30.56sjhillbut all of the macros do things in term of longs no matter what
04:31.00mjn3SpanKY: there's still an issue with cross vs native libstdc++ config.  i'm looking into it
04:31.38sjhilla long is always returned and then is casted, even it is a demotion in type
04:31.40mjn3but what does the buf++ do?  the macros have no guarantee on the type passed, do they?
04:32.09sjhillno
04:32.18sjhillbut it gets cast to a u_int32_t
04:32.22sjhillregardless
04:32.34sjhillis my *((u_int32_t*)buf++)) incorrect?
04:32.52sjhilli want buf cast to a u_int32_t pointer and incremented
04:32.59sjhilli don't have my C book handy
04:34.08SpanKYmjn3: i havent gotten the gall up yet to ask gcc devs to change their config files to remove the '-gnu*' ;)
04:34.58mjn3sjhill: i remember fixing some things like that in my string code a while back.  you could run a test
04:36.26mjn3SpanKY: heh
04:37.16mjn3i haven't even tried building for anything other that x86 and mipsel.  in particular, i'm not sure about one of the cris-related patches
04:37.22sjhillmjn3: can you point me to that?
04:37.40mjn3sjhill: to what?
04:37.51sjhillnm
04:42.03mjn3doing the following in a loop
04:42.07mjn3<PROTECTED>
04:42.07mjn3<PROTECTED>
04:42.32mjn3winds up incrementing p by 1 char each time for p a char *
04:42.53mjn3i.e. it won't do what you want
04:48.54mjn3my suggestion earlier works
05:00.27sjhill*nod*
05:00.30sjhillokay
05:00.34sjhilli'll fix that stuff tomorrow
05:00.37sjhillthx
05:00.40sjhillgood night
05:31.46CIA-1003mjn3 * r10220 10buildroot/toolchain/gcc/4.0.0/303-c99-complex-ugly-hack.patch: Ugly hack to force the configuration for the cross libstdc++ to fail for complex funcs we don't yet support.
05:32.35mjn3ok... now the configs for libstdc++ match for both cross and native builds.  ugly temporary workaround admittedly
05:36.04anderseenice
05:47.14*** join/#uclibc courtc_ (~courtc@adsl-154-39-94.asm.bellsouth.net)
07:13.10CIA-1003andersen * r10221 10uClibc/ldso/ldso/mips/ (dl-sysdep.h elfinterp.c resolve.S):
07:13.10CIA-10On mips, gdb explicitly looks for the symbol "__dl_runtime_resolve" so change
07:13.10CIA-10the name of our mips resolver function to match gdb's expectations.
07:23.10SpanKYandersee: hey, in uclibc/libc/sysdeps/i386/syscall.S
07:23.22SpanKYthe return value check
07:23.23SpanKY<PROTECTED>
07:23.23SpanKY<PROTECTED>
07:23.31SpanKYshouldnt that be jae ?
07:25.12SpanKYglibc utilizes jae
07:25.13SpanKYhttp://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/i386/syscall.S?rev=1.11&content-type=text/x-cvsweb-markup&cvsroot=glibc
07:25.21SpanKY<PROTECTED>
07:25.21SpanKY<PROTECTED>
07:28.23SpanKYerr nm, the two differ in how they treat the error
07:28.26SpanKYforget me :)
07:38.20SpanKYerr, the i386 code should be 'jb' not 'jbe' ?
07:55.23*** join/#uclibc ashes (~ashes@modemcable202.48-130-66.mc.videotron.ca)
10:13.18*** join/#uclibc edrx (~user@200.141.112.167)
10:14.43edrxhi
10:15.14edrxI just wrote my first /etc/init.d/rcS for a busybox-only system
10:15.34edrxbut I think it is wrong
10:15.41edrxhere it is:
10:15.42edrx/etc/init.d/rcS
10:15.53edrx#!/bin/sh
10:15.54edrx. /etc/profile
10:15.54edrxprep2ep
10:15.55edrxtelnetd
10:15.55edrxinit
10:15.57edrx<PROTECTED>
10:16.19edrx(prep2ep is a shell function defind in /etc/profile)
10:16.37edrxthe problem is that init is saying
10:16.52edrx"Usage: init
10:17.10edrxInit is the parent of all processes."
10:17.54edrxand so I'm not getting job control.
10:33.11thomasezWee, lzmatools for buildroot working.
11:14.34*** part/#uclibc edrx (~user@200.141.112.167)
14:38.34*** join/#uclibc ambroseL (~bjb@67.71.251.210)
14:39.47*** join/#uclibc mjn3 (~mjn3@c-67-164-173-93.hsd1.co.comcast.net) [NETSPLIT VICTIM]
14:39.47*** join/#uclibc CIA-10 (~CIA@flapjack.navi.cx) [NETSPLIT VICTIM]
15:25.17*** join/#uclibc CIA-10 (~CIA@flapjack.navi.cx) [NETSPLIT VICTIM]
16:26.31mjn3looks like there's a mips-specific bug in ld from binutils 2.16.90.0.2  <grumble>
16:49.28solarfun ;/
16:57.06mjn3here's a bit of the readelf -a output for libdl.so.  actually, a diff from two different builds using the same toolchain
16:57.33mjn3<PROTECTED>
16:57.33mjn3-    25: 000361b0     0 NOTYPE  <unknown>: 5 DEFAULT  UND MIC
16:57.33mjn3+    25: 00000012     6 <OS specific>: 12 <unknown>: 4 PROTECTED    9
16:57.33mjn3<PROTECTED>
16:58.24mjn3with the last 2.15* i used, free occurred right after _fbss.  looks like an off-by-one kind of error
17:00.15mjn3think it is mips specific.  doing an x86 build now
18:29.51solaris there an easy way to alias an applet? like sash for ash
21:01.32mjn3solar: you'd have to change the applet table in busybox since the main busybox app checks the invocation name and does a bsearch in the applet table to find the appropriate app_main to run
21:05.46solarahh like CONFIG_TEST in ./include/applets.h
21:06.13mjn3yes
21:07.28mjn3just remember that it does a binary search so the applet table must remain sorted
21:10.31solarhttp://rafb.net/paste/results/XheBBR22.txt
21:11.34solarany idea how many bytes that would add?
21:12.18mjn3one more entry in the table struct plus the bytes for the "sash" string
21:13.14mjn3that's my guess anyway
21:14.13mjn3was just popping in between errands.  back later
21:14.26solarthanks. cya later.
21:15.05*** join/#uclibc zcram (~zcram@xor.uninet.ee)

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with blootbot logs, split per channel, etc.