=== asac_ is now known as asac [11:56] asac: did it bumb? :D [13:42] armin76: the build failed ... but but but ... i dont see any error ;) [13:43] worst case i would say ;) [13:43] let me try to get the log somewhere [13:43] * lool wins \o [13:45] asac: Was a date set to move armel to archive.u.c? [13:47] http://people.canonical.com/~asac/tmp/chromium-browser_4.0.260.0~svn20091128r33239-0ubuntu1~ucd1_armel.build.bak.bz2 [13:47] lool: ^^ [13:47] no error ;) [13:47] but still build failed [13:47] i ran the last command you can se there ... linked fine ;) [13:47] not sure whats going on [13:47] i guess OOM ;) [13:50] lool: not sure that it was discussed. was that prediscussed/should i add that as a lucid goal? [13:50] asac: scons: *** [/home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o] Error 1 [13:50] as -o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s [13:50] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s: Assembler messages: [13:50] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s:2: Error: junk at end of line, first unrecognized character is `,' [13:51] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/third_party/icu/linux/icudt42l_dat.s:5: Error: unrecognized symbol type "" [13:51] asac: Doesn't look like oom to me [13:51] oh [13:52] darn chromium build system [13:52] --keep-going [13:52] what a bad invention ;) [13:52] i looked from the back ;) [13:52] --keep-going is called from the rules [13:52] yes [13:52] thats the bad thing [13:52] So you could trash it, it's not scons' default [13:52] i dont know why fta has it [13:52] sure [13:52] already done [13:52] Well if you know it's there, I find it helpful [13:52] also did it before, just took latest snapshot and forgot to remove that [13:53] why would you want to keep going? because scons is too slow to do quick incremental builds? [13:53] The nice thing is that you know there is only this one error from everything which could be build in this pass; perhaps other errors will popup later, but it tested a good part of the build already [13:54] You might want to "fire the build and forget" and then look back at all errors, especially on random arches [13:54] (on buildds) [13:54] It's a compromise because it also wastes a lot of machine time if things go wrong every time; if you do fix build failures, it saves machine time though [13:54] Anyway, matter of taste [13:55] right [13:55] jocote:/tmp/icudt42l_dat.s [13:55] lool: ^ [13:56] * asac gets coffee ;) [13:58] asac: I'd disable stack protection for now; it seems to be broken in the toolchain here; would be nice to keep the test case though [13:58] asac: who won? :) [13:58] asac: Just pass -fno-stack-protector [13:58] in CFLAGS [13:59] armin76: You're a gentoo guy right? [13:59] Hi [13:59] lool: yep [14:00] armin76: I find http://www.gentoo.org/proj/en/hardened/gnu-stack.xml really nice [14:00] to build my ubuntu-arm image for beagle board, should i have ubuntu on my development PC (i.e. to be compatible with rootstock) or i can use kubuntu without problems ? [14:01] armin76: What do you work on in gentoo? arm porting? [14:01] i would save time to install ubuntu [14:01] lool: we're nice ppl :P [14:01] giorgio__: kubuntu should be just fine [14:01] i'm asking 'cause i cannot fetch rootstock from apt-cache search [14:01] lool: http://armin762.wordpress.com/about/ [14:01] giorgio__: kubuntu and ubuntu are built from the same underlying packages, just a different selection / default config, so worst case you have to install a couple more packages [14:01] giorgio__: Which release are you on? [14:02] i installed an old one, and the let it upgrade itself, it should be kubuntu 9.04 [14:02] maybe i have tu follow the instruction for Jaunty ubuntu ? [14:03] armin76: good to know, thanks [14:04] giorgio__: rootstock is shipped in ubuntu/kubuntu since karmic [14:05] giorgio__: So either upgrade to karmic (you'll have to at some point anyway ;-) or add the rootstock jaunty PPA to your config [14:05] giorgio__: Also note that rootstock is in universe, so this needs to be enabled (isn't by default) [14:07] ok thanks, i'm following the instructions for jaunty, i think should not be different [14:07] hope difficult either :D [14:07] asac: I can't figure why "," would be an invalid char; it seems fine from the example in http://www.gentoo.org/proj/en/hardened/gnu-stack.xml [14:10] icu sucks [14:10] 4.2.1 fails for me on arm, i think it was assembler related thing as well [14:10] haven't had time to look at it [14:10] but on debian it built fine... [14:18] lool: using @progbits helps [14:18] err [14:18] %progbits ;) [14:18] like on the gnu-stack.xml [14:19] http://paste.ubuntu.com/331089/ [14:19] does that make sense ;)? [14:19] %object i did too ;) [14:21] asac: Yeah I spotted the @ versus %, but other examples say @; not sure what it means [14:21] lool: i changed %progbits and %object ;) ... whats the difference ;) [14:24] wow ... really huge .s file ;) [14:24] 6M gzipped ;) [14:25] lool: so @ works on x86 ... but % works too [14:26] readelf -S looks identical at least [14:27] lool: where is a @ example? [14:28] https://svn.pardus.org.tr/pardus/2009/stable/system/devel/gcc/files/note-gnu-stack.dpatch [14:28] seems %progbits is used for arm stuff [14:28] everywhere else its @objcet [14:28] err @progbits [14:28] too bad i dont have lucid chroot [14:30] lool: i assume you have no lucid toolchain on your board and you could check whether thtas still needed? [14:33] asac: i won! [14:33] now you owe me an armv7 board [14:34] armin76: we will see ;) [14:34] armin76: i am still convinced your talent would be better invested in the ubuntu project ;) [14:36] now the build is at linking stage [14:36] i guess that will consume all damn mem and swap together ;) [14:47] "Note on targets where the @ character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the % character." [14:47] lool: ^ [14:47] http://sourceware.org/binutils/docs-2.20/as/Section.html#Section [14:49] ok that explains it ... guess we need and #if defined... [14:49] but which one ;) [15:13] asac: I dont have a lucid host yet [15:14] asac: What is that .s generated from? [15:15] good question ;) [15:15] let me check [15:17] From ./build-tree/src/third_party/icu/source/data/in/icudt42l.dat [15:18] i dont see where it gets generated [15:18] It might be pregenerated in the tree [15:19] right thats what i think [15:19] It's really slow to unpack lzma though [15:19] -rw-r--r-- fta/fta 25347229 2009-11-26 16:02 src/third_party/icu/linux/icudt42l_dat.s [15:19] so we either need to hope that % really works everywhere [15:19] It is pregenerated [15:19] chromium's build system sucks :P [15:19] or we have to ship two different files ;) [15:19] % works at least here on x86 [15:19] feels ugly though if gnu docs say @ ;) [15:20] asac: It might mean something else on x86? [15:21] lool: the readelf looked identical at least ;) [15:21] # These are hand-generated, but will do for now. The linux [15:21] # version is an identical copy of the (mac) icudt42l_dat.s file, [15:21] # modulo removal of the .private_extern and .const directives and [15:21] # with no leading underscore on the icudt42_dat symbol. [15:21] 'linux/icudt42l_dat.s', [15:21] right.... but _how_ are they hand generated ;) [15:22] - {mac,linux}/icudt42l_dat.s : Built on Mac and Linux with all the [15:22] patches above applied and checked in. [15:22] - source/data/in/icudt42l.dat : Built on Linux with all the patches [15:22] above applied, [15:22] 11. Pre-built data libraries are checked in. [15:22] i see that section [15:22] build-tree/src/third_party/icu/README.google [15:23] Given that it's to put this in a symbol in a .o, I wonder whether they could generate a C file instead [15:24] yes. but you have to wrap each line with asm("... right? [15:25] I think it's just data; they could export a const array [15:26] The declaration says it's not executable anyway [15:26] So something like unsigned long data[] = {0x...}; [15:27] hmm [15:27] + static [15:27] It's in section .rodata, so clearly const [15:27] yep [15:27] .align 8 => can probably be achieved with __attribute__ [15:27] Not sure what .type icudt42_dat,%object means [15:28] i asked on the #chromium channel now ... lets see if anyone answers [15:28] http://sourceware.org/binutils/docs-2.20/as/Type.html#Type [15:28] "Mark the symbol as being a data object. " [15:29] Right just landed on that page as well [15:29] hmm so STT_OBJECT? [15:29] Does this exist in C? [15:29] I'm not even sure this stuff is needed [15:30] ok STT_OBJECT works [15:31] in C? [15:32] no in .s [15:32] .type icudt42_dat STT_OBJECT [15:32] rather than ,@object [15:33] doc says thats the gnu arch independent way [15:33] Well yes, that's the same thing [15:33] that reduces the problem to the progbits ;) [15:33] I was proposing to move this whole .s stuff to .c to aovid the porting issue [15:33] which doesnt really help :) [15:33] right [15:33] i understood [15:33] Oh the object part was rejected as well? [15:33] yes [15:34] @ is a comment on arm asm [15:34] Ok didn't see that far [15:34] Right [15:34] Note on targets where the @ character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the % character. [15:34] http://sourceware.org/binutils/docs-2.20/as/Section.html#Section [15:34] hell ... i want a portable for that too ;) [15:34] Yup, read that too; just didn't spot use of @ in object [15:34] or know how the .s is generated so we can create a .c [15:34] ah ok [15:35] Well to me it seems the .s is just the bytes from the .dat [15:35] #chromium channel folks are laggers ... noone replying sundays as it seems ;) [15:35] haha [15:35] yes. but there must be ascript or something ;) [15:36] so we want to use static unsigned long icudt42_dat[] { .... } ? [15:37] feels like we could even postprocess that from the .s file ;) [15:46] echo "const unsigned long icudt42_dat[] = {" > out.c; grep ^\.long icudt42l_dat.s | sed -e 's/\.long//' | sed -e 's/$/,/' >> out.c; echo '};' >> out.c [15:47] might complain about final , ;) [15:49] lool: isnt the alignment automatically done by gcc? [15:49] asac: Only on size long [15:49] hmm [15:49] It might be more, but how do you know? [15:51] so __attribute__ ((aligned (8))); ? [15:51] Yup [15:52] echo "const unsigned long icudt42_dat[] = {" > out.c; grep ^\.long icudt42l_dat.s | sed -e 's/\.long//' | sed -e 's/$/,/' >> out.c; echo '} __attribute__ ((aligned (8)));' >> out.c [15:52] I checked build-tree/src/third_party/icu/linux/icudt42l_dat.s, it starts with the same bytes as build-tree/src/third_party/icu/source/data/in/icudt42l.dat [15:52] hmm [15:52] ok so we could write the full binary generator [15:52] isnt there such a tool already ;) [15:52] must be somewhere [15:52] asac: FYI, the conversion is completely unportable like this [15:52] It uses long despite the fact that it's represented differently on little endian and big endian arches [15:53] I think we just want some uint8_ts [15:53] maybe the code consuming this does the endianess shuffeling? [15:54] do we know? [15:54] I have my doubts [15:55] why is ICU such a mess ;) [15:55] do you know anything about touch screen issues with the beagleboard ? [15:55] I did a grep -rl icudt42_dat build-tree/src/* but couldn't find where the symbol was used exactly [15:55] heh [15:55] asac: and the end of the file is also the same [15:55] right [15:55] thats expected (now) [15:56] so the gcc on the out.c runs for 5 minutes already ;) [15:56] ok to be fair chromium is linking in the background ;) [15:57] 10515 asac 20 0 494m 140m 84 R 1.3 29.8 1:56.70 cc1 [15:58] yep ;) [15:58] thats the out.c one [15:58] as was much faster ;) [15:58] I'm just scared with the memory use [15:58] yeah. probably HUGE array gets parsed first [15:58] let me abort that for now [15:59] give some air to breath to ld [15:59] ;) [15:59] ld is also hungry [15:59] 8683 asac 20 0 1245m 352m 76 D 3.2 74.7 5:59.52 ld [15:59] right [15:59] but thats expected [16:00] chromium takes like 3G [16:00] wow [16:00] we only have 512m :( [16:00] for linking [16:00] it links everything static [16:00] and does that for 1000 binaries or so ;) [16:00] all tests etc. [16:01] lool: did you succeed with your full/dynamic arm chroot thing? [16:01] I stopped at UDS [16:01] kk [16:01] I need to finish this [16:01] I clearly didn't manage to avoid binfmt though [16:02] It might be possible with some awful hacks [16:08] most chromium devs use gold instead of regular ld, but i don't know for arm [16:08] do you know where this icu blob is actually used ;)? [16:08] icudt42_dat [16:09] Assembling /build/buildd/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o [16:09] Creating library /build/buildd/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/lib/libicuuc.a [16:09] yes [16:09] asac: No, as I said above I grepped for it and couldn't find it [16:09] right thats why i asked fta ;) [16:09] (sorry for missing nick) [16:09] I found it referenced in other .a files, but I didn't see where the symbol was used [16:09] Oh sorry [16:09] lool: referenced in other .a files? [16:10] which one? [16:10] Sorry off buffer [16:10] grepping again [16:10] :) [16:12] wich is the newest kernel version and where i can get the link to pass to rootstack ? [16:13] http://code.google.com/p/chromium/issues/detail?id=22369 [16:13] giorgio__: We dont support beagleboard kernels sadly [16:14] build-tree/src/sconsbuild/Release/lib/libicuuc.a [16:14] build-tree/src/sconsbuild/Release/lib/libicudata.a [16:14] asac: ^ [16:14] it continues [16:15] nm on those?nm build-tree/src/sconsbuild/Release/lib/libicuuc.a | grep icu.*_dat U icudt42_dat [16:15] lool: i found it, simply navigate in the rcn-ee.net website [16:15] tnx anyway [16:15] nm ./build-tree/src/sconsbuild/Release/lib/libicudata.a [16:15] icudt42l_dat.o: [16:15] 00000000 R icudt42_dat [16:16] build-tree/src/sconsbuild/Release/obj/icu/icuuc/source/common/udata.o [16:16] build-tree/src/sconsbuild/Release/obj/icu/icudata/linux/icudt42l_dat.o [16:17] Oh right it's mentionned in some tests as well [16:18] build-tree/src/third_party/icu/source/common/umapfile.c:# define U_ICUDATA_ENTRY_NAME "icudt" U_ICU_VERSION_SHORT U_LIB_SUFFIX_C_NAME_STRING "_dat" [16:19] lool: ^ [16:19] so U_ICUDATA_ENTRY_NAME [16:19] lool: why don't you support beagleboard? [16:20] loaded question i guess [16:20] we provide rootstock ;) [16:20] asac, lool: which version are you using, in r30145, there's a fix for icu on arm, but 1 month old now [16:20] asac: did you saw the link fta posted? [16:20] fta: I use latest daily [16:20] fta: link to that commit? [16:20] hmm [16:21] asac: but thats not commited? [16:21] maybe icu snapshot wasnt bumped to latest? [16:21] oh, it is [16:21] well, i don't understand google code :P [16:21] here is the patch http://codereview.chromium.org/338031 [16:21] is icu a copy? not a on-demand checkout? [16:21] ok [16:21] heh [16:21] yes [16:22] thats the fix [16:22] though .type icudt42_dat STT_OBJECT is "better" ;) [16:22] i know, but it's strange you still see it though [16:22] fta: why isnt that in daily? [16:22] guess it wasnt committed? [16:23] it was, as i said, it's in r30145 [16:23] when was it backed out ;)? [16:23] when they merged icu? [16:24] can you confirm that its not in anymore? or is our tarball bogus? [16:26] checking [16:26] asac: http://paste.ubuntu.com/331166/ [16:27] yeah [16:27] 17:18 < asac> build-tree/src/third_party/icu/source/common/umapfile.c:# define U_ICUDATA_ENTRY_NAME "icudt" U_ICU_VERSION_SHORT U_LIB_SUFFIX_C_NAME_STRING "_dat" [16:27] 17:19 < asac> lool: ^ [16:27] so grepping for U_ICUDATA_ENTRY_NAME gives the usesin code [16:27] not sure if we should check if that deals with endianes properly there [16:31] chromium pulls /trunk/deps/third_party/icu42@32651 so it's in. are you sure you're patching the same file? [16:31] so this was committed to icu tree? [16:31] where i sthe tree? [16:31] (svn) [16:32] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/ [16:32] thx [16:33] asac: Ah cool, that's what I would have grepped next, but I feared being overwhelmed with results [16:35] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?revision=32640&view=markup [16:35] fta: ^^ [16:35] its clearly not on trunk anymore [16:36] i dont even see any commit backing that out ;) [16:36] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=26784&view=log [16:36] how can i get longer log for that? [16:36] oh maybe they added it to 38? [16:36] viewvc is crap [16:36] no ... its not there either :/ [16:36] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu38/linux/icudt38l_dat.s?view=log [16:36] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu38/linux/icudt38l_dat.s?revision=24730 [16:38] its odd if i look at the diff to previous of the ARM portable commit [16:39] it _adds_ the @ stuff [16:39] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/linux/icudt42l_dat.s?r1=25651&r2=26784 [16:39] oh ;) [16:39] its on the right [16:39] didnt even see anything of that on my screen :) [16:39] yeah. so this regressed in commit http://src.chromium.org/viewvc/chrome?view=rev&revision=29728 [16:40] reverted :) [16:42] asac: http://paste.ubuntu.com/331180/ [16:42] asac: Change "L>*" to "L*" to use native encoding; "<" is LE, ">" is BE [16:43] (nothing is whatever the host runs == native) [16:43] And tweak $chunk and sprintf as you please [16:43] lool: asac was compiling with -j8 [16:43] * armin76 runs [16:44] ? [16:44] asac: j/k [16:44] asac: if you talk to upstream, would love if you made them generate a .s or .c at build time; it's one less large and weird sourcefile and more maintainable for us in such cases [16:44] ack [16:45] thats what we should be aiming for i guess [16:47] asac, 32640 did it [16:48] crbug.com/20406 [16:49] love that URL scheme [16:50] fta, asac: So it's pretty clear the fact that the generation happens manually participated in this issue.... :-( [16:50] anyway /me runs & [16:50] enjoy [16:53] http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu42/README.google look at 11. [16:57] asac, i will reopen the bug [16:57] yes... already read [16:57] (i'm bugcontrol there) [16:58] fta: can you suggest to generate those on the fly? [17:00] it seems difficult based on all the changes mentioned in the readme [17:00] from what i understand the changes are done to the .dat file [17:00] so that one would be the base for mac/linux at least [17:03] which bug will you open= [17:03] there were two ;) [17:04] how much faster would chromium finish if built without tests? ;) [17:04] :-P [17:04] I build it in 20 minutes here ;) [17:06] g++ -o /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/sconsbuild/Release/ui_tests [17:06] i reopened crbug.com/20406 [17:07] without comment? [17:07] hmm that bug is a different one [17:07] not the ARM regression bug [17:07] oops, crbug.com/22369 [17:07] bad paste buffer [17:07] http://code.google.com/p/chromium/issues/detail?id=22369 [17:25] asac, anything else broken on arm? [17:25] cant tell ;) [17:25] build is slow [17:25] linking [17:25] atm [17:26] fta: we should add armv7=1 to GYP_DEFINES [17:26] if we are on armv7 i guess [17:26] at least i added it here ;) [17:27] could you please paste a dpkg-architecture? [17:27] http://paste.ubuntu.com/331205/ [17:27] doesnt show if we are on v7 [17:28] uname -m? [17:28] $ uname -m [17:28] armv7l [17:28] better [17:28] do you have other flavors you want to support? [17:28] i am not sure we want to not use the uname -m ... rather something that figures if the toolchain defaults to v7 [17:29] fta: i think it would be nice if it also can be compiled on armv7 machines for hardy [17:29] thats why we need to use toolchain or CFLAAGS or something to determine that [17:40] fta: i think we want to use that for lucid and later [17:40] for now [18:50] fta: tests are running ;) [18:50] ## list of FAILED tests: [18:50] [ FAILED ] ConditionVariableTest.FLAKY_MultiThreadConsumerTest (796 ms) [18:51] [WARNING] /home/asac/chromium-browser-4.0.260.0~svn20091128r33239/build-tree/src/testing/gtest/src/gtest-death-test.cc:741:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test couldn't detect the number of threads. [18:52] Timeout: aborting command ``./base_unittests'' with signal 9 [18:52] Killed [18:52] quite a lot tests work though [18:52] nice [20:55] chromium-browser .deb seems to be done on jocote ;) [20:56] fta: package is building -dbg .deb still ... is it normal that i see a test_shell_test process running still? [20:56] baseunit_tests too afaict [20:56] 17863 asac 20 0 77348 8 4 R 33.0 0.0 66:33.30 base_unittests [20:56]