| === asac_ is now known as asac | ||
| === ogra_ is now known as ogra | ||
| armin76 | ogra: lool: does ubuntu support the netwalker? | 12:53 |
|---|---|---|
| lool | armin76: The netwalker ships with a Canonical Ubuntu OEM version | 13:40 |
| lool | I have one here | 13:41 |
| lool | But it's not supported in vanilla Ubuntu | 13:41 |
| lool | It's mostly imx51 though | 13:41 |
| asac | fta: great. chromium works | 13:52 |
| asac | please use gcc-4.3 for now | 13:53 |
| asac | on armel | 13:53 |
| asac | so its gcc 4.4 bustage that caused this mess | 13:53 |
| asac | i already have an idea which compile flags those are | 13:53 |
| asac | let me commit the hack to workaround the issue for -m32 | 13:53 |
| asac | armin76: ^^ | 13:53 |
| fta | ok | 13:54 |
| fta | what about the other flags? | 13:55 |
| asac | have to test | 13:55 |
| asac | let me first get this working | 13:55 |
| asac | one second | 13:55 |
| asac | my guess is that its the -fdata-sections and -ffunction-sections flag combined with --gc-sections linkking | 13:56 |
| asac | i will drop those to test that | 13:56 |
| asac | they are supposed to remove symbols supposely not used from what i understand | 13:56 |
| asac | feels rarely tested ;) | 13:57 |
| asac | fta: btw, the GCC version hook you hvae in rules doesnt work with gyp=make | 13:58 |
| fta | really? hm | 13:58 |
| fta | how did you test then? | 13:58 |
| asac | i fixed rules too | 14:00 |
| asac | ;) | 14:00 |
| asac | http://pastebin.com/f5757e288 | 14:01 |
| asac | ok all committed | 14:03 |
| armin76 | asac: but does google work? | 14:04 |
| asac | yes | 14:04 |
| asac | everything works | 14:04 |
| asac | and is rockingly fast ... even over ssh ;) | 14:04 |
| zumbi | congrats ! :-) | 14:05 |
| asac | hehe | 14:05 |
| asac | let me see how it is on real X | 14:05 |
| fta | strange, CC and CXX are supposed to be used by gyp.. probably another bug there | 14:07 |
| asac | 5 seconds on first startup | 14:08 |
| asac | fta: yes. its a bug in the make generator most likely | 14:08 |
| asac | i saw that scons generator at least looks at those | 14:08 |
| fta | i will talk with the author of this generator | 14:08 |
| asac | while the make one doesnt even reference those | 14:08 |
| * asac a bit happy | 14:12 | |
| fta | btw, i'm working on setting up a dev-channel, between the beta-channel and pure dailies | 14:17 |
| asac | i always thought that was the plan | 14:18 |
| asac | actually i thought that the dailies are more or less redundant | 14:18 |
| asac | at least for users (and most ubuntu devs) the -dev channel is more fruitful i guess | 14:19 |
| asac | fta: so if i remove stuff from ppa ... will that give more space? | 14:19 |
| fta | if users want to switch, i don't mind, but from the feedbacks i got with the beta, users prefer dailies | 14:20 |
| * asac considers to upload rather than wait for a new daily to not upload a new tarball | 14:20 | |
| asac | yeah. but i think -dev is more what they want. but we will see | 14:20 |
| asac | just push the builds to 4am for chromium ;) | 14:20 |
| asac | hehe | 14:20 |
| asac | last time i said that | 14:20 |
| asac | i promiss | 14:21 |
| fta | i have new problems with those 3 ppas now, like should i align the codecs and gyp on each version, or let those 2 track trunk.. | 14:28 |
| lool | asac: chromium on armel weee \o/ | 14:31 |
| asac | yeah | 14:31 |
| asac | lool: do you remember why NEON is disabled for imx? | 14:32 |
| asac | someone said CPU hangs ... is that understood? | 14:32 |
| asac | fta: i dont know. isnt gyp more or less stable enough to do that on a as-needed base? | 14:35 |
| fta | asac, well, yes | 14:36 |
| asac | and codecs? | 14:38 |
| fta | the code itself is quite stable, but they keep adding patches (mostly to fix security stuff) and build flags may change | 15:05 |
| asac | darn. bad syntax error in my commit ;) | 15:06 |
| * asac reuploads | 15:06 | |
| asac | ok retrying with gc 4.4 but with section gc dropped | 15:17 |
| asac | its kinda strange. the CC=... isnt honoured for v8 altogether | 15:35 |
| asac | still it helped here ;) | 15:35 |
| asac | sigh. we should definitly enable V=1 on builders | 15:35 |
| asac | there is no reason not to imo | 15:36 |
| armin76 | ricing | 15:42 |
| armin76 | lool: why nageia doesn't build stuff anymore? | 15:43 |
| lool | asac: TO1 and 2 have broken NEON implementations which will hang with some NEON code | 16:05 |
| lool | asac: But TO3 fixes it | 16:05 |
| lool | asac: It's a silicon bug, and apparently you can trigger it in some uncommon circunstances, but valid uses cases | 16:05 |
| lool | Ideally, we'd have a kernel patch to enable it only on TO3 and later at run time, but I don't think the kernel has any provision for this | 16:06 |
| lool | armin76: I have no idea | 16:06 |
| lool | armin76: Sometimes the buildd hang | 16:06 |
| * armin76 blames rabeeh | 16:10 | |
| asac | so since when is thumb (not 2) supported? i guess its good for karmic, but not jaunty? | 17:21 |
| lool | asac: ? | 17:30 |
| lool | asac: Thumb has always been working | 17:30 |
| lool | AFAIK | 17:30 |
| asac | cool | 17:30 |
| lool | Only Thumb 2 and NEON had issues in TO before 3 | 17:30 |
| * asac enables thumb everywhere then | 17:30 | |
| armin76 | g++ -pthread -fno-exceptions -fvisibility=hidden -Wall -D_FILE_OFFSET_BITS=64 -fno-ident -fdata-sections -ffunction-sections -fno-asynchronous-unwind-tables -fomit-frame-pointer -O3 -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DENABLE_LOGGING_AND_PROFILING -DENABLE_DEBUGGER_SUPPORT -D__STDC_FORMAT_MACROS -DDISABLE_NACL -DV8_TARGET_ARCH_ARM -DCHROMIUM_BUILD -DNDEBUG -DNVALGRIND -Iv8/src -Iv8/src/arm -MMD -MF out/Release/ob | 18:16 |
| armin76 | j.host/v8_base/v8/src/arm/cpu-arm.o.d.tmp -c -o out/Release/obj.host/v8_base/v8/src/arm/cpu-arm.o v8/src/arm/cpu-arm.cc | 18:16 |
| armin76 | /var/tmp/portage/www-client/chromium-9999/temp/ccs57NS8.s: Assembler messages: | 18:16 |
| armin76 | /var/tmp/portage/www-client/chromium-9999/temp/ccs57NS8.s:49: Error: selected processor does not support `bkpt 0' | 18:16 |
| armin76 | make: *** [out/Release/obj.host/v8_base/v8/src/arm/cpu-arm.o] Error 1 | 18:16 |
| * armin76 complains | 18:16 | |
| armin76 | ah, stupid thing | 18:21 |
| asac | hmm ... odd ... what did i do in my build to fix this LOGGING_AND_PROFILING thing | 18:22 |
| asac | err | 18:22 |
| asac | this virutal function call thing | 18:22 |
| asac | it happens again with fresh builds ;) | 18:22 |
| armin76 | hah | 18:23 |
| asac | i remember i removed a bunch of -D stuff | 18:23 |
| asac | so its probably one of those | 18:23 |
| asac | B | 18:24 |
| asac | VALGRIND ... maybe | 18:24 |
| asac | or DEBUGGER support ;) or really profiling and debugging | 18:24 |
| * asac wonders what this mksnapshot thing does | 18:26 | |
| armin76 | fta: why isn't the sse2 patch applied upstream? | 18:28 |
| asac | the patch isnt applied in our packages | 18:29 |
| asac | hmm | 18:29 |
| asac | seems it is ;) | 18:29 |
| armin76 | asacfail | 18:30 |
| asac | + # Disabled: see http://code.google.com/p/chromium/issues/detail?id=9007 | 18:31 |
| asac | Result: layout tests require SSE2, normal builds probably shouldn't and Google Chrome | 18:31 |
| asac | packages don't. We don't control other packages. | 18:31 |
| asac | "I understand it's not ideal but as Chrome Linux is now shipped without those SSE2 | 18:32 |
| asac | flags, i don't see why Chromium has to." | 18:32 |
| armin76 | ricing! | 18:32 |
| asac | dunno what that means ;) | 18:32 |
| fta | armin76: because they don't want it in chrome, it makes the testsuite regress | 18:34 |
| armin76 | i see | 18:35 |
| armin76 | asac: echo | gcc -dM -E - | grep ARCH <- what does this return to you? | 18:35 |
| asac | echo | gcc -dM -E - | grep ARCH | 18:36 |
| asac | #define __ARM_ARCH_6__ 1 | 18:36 |
| asac | but i am on karmic | 18:36 |
| asac | echo | gcc -dM -E - | grep ARCH | 18:36 |
| asac | #define __ARM_ARCH_7A__ 1 | 18:36 |
| asac | thats on lucid | 18:36 |
| asac | armin76: ^ | 18:37 |
| armin76 | i see, thanks | 18:37 |
| asac | http://people.canonical.com/~asac/screenshots/ffox35_vs_chromium_armel_sunspider.png | 18:47 |
| asac | odd that gyp generator make doesnt create clean targets ;) | 18:48 |
| asac | http://people.canonical.com/~asac/screenshots/chromium_karmic_armel_whatsmyuseragent.png | 18:56 |
| asac | armin76: ^ | 18:56 |
| armin76 | asac: quick! | 18:57 |
| asac | just wanted to encourage you not to give up ;) | 18:58 |
| asac | did you get further than the prop you posted above now? | 18:58 |
| armin76 | nope not yet | 19:00 |
| armin76 | that error happened because we tend to have the packages respect the cflags | 19:01 |
| armin76 | and we don't use default -march on gcc | 19:01 |
| armin76 | so it was building for armv4t as i forgot to add -march | 19:01 |
| asac | kk | 19:02 |
| asac | ok now it seems to work | 19:06 |
| asac | those ugly gcc44 flags cause all the trouble | 19:06 |
| asac | 'conditions': [ | 19:06 |
| asac | [ 'gcc_version==44', { | 19:06 |
| asac | 'cflags': [ | 19:06 |
| asac | # Avoid gcc 4.4 strict aliasing issues in dtoa.c | 19:06 |
| asac | '-fno-strict-aliasing', | 19:06 |
| asac | # Avoid crashes with gcc 4.4 in the v8 test suite. | 19:06 |
| asac | '-fno-tree-vrp', | 19:06 |
| asac | ], | 19:06 |
| asac | thats causing bustage for me | 19:06 |
| armin76 | and why are you using that? | 19:07 |
| asac | me? | 19:08 |
| asac | thats not me... thats chromium | 19:08 |
| asac | they just run g++ --version ... and if its 4.4 they use those | 19:08 |
| asac | would be interesting to know which one it is | 19:09 |
| asac | mos tlikely the one preventing crashes ;) | 19:09 |
| armin76 | ah | 19:09 |
| fta | we have tons of bugs that are 44 related | 19:09 |
| asac | i will narrow it down now ... pushed one more round to builders to see if it succeeds there | 19:10 |
| fta | like http://crbug.com/28749 | 19:10 |
| asac | imo they play too much with optimization flags ;) | 19:11 |
| asac | that calls for troubles ;) | 19:11 |
| asac | but lets see | 19:11 |
| * asac goes back to 4.4 locally without the no-tree-vrp | 19:11 | |
| fta | you will crash in v8 | 19:13 |
| asac | well. i crash with both for sure ;) | 19:16 |
| asac | even on 4.3 | 19:16 |
| asac | at least i dont run test suite ;) | 19:17 |
| asac | hehe | 19:17 |
| asac | darn. wanted to enable V=1 for that ppa upload :/ | 19:23 |
| asac | hmm failed on the builder again :/ | 19:55 |
| asac | wonder if i really included everything | 19:56 |
| armin76 | asac: on the GYP_DEFINES you're still using gcc_version=44 | 19:58 |
| asac | no | 20:08 |
| asac | that happens automatically | 20:12 |
| armin76 | ah ok | 20:12 |
| asac | hmm | 20:12 |
| * asac scratches head | 20:13 | |
| asac | fta: so is VERBOSE = 1 really that bad that we dont know what flags got passed if something fails on builders ;)? | 20:16 |
| === jmc93739653_ is now known as jmc93739653 | ||
| fta | well, it's easier to spot errors without it. verbose makes very long lines filling the screen, that's why it's off by default | 20:18 |
| === jmc93739653 is now known as jmc93739653_ | ||
| asac | heh? | 20:18 |
| asac | i think now with make build fails right away anyway | 20:18 |
| asac | and you usually want to see the lines | 20:18 |
| asac | if there are build failures | 20:19 |
| fta | failing right away is not related to scons vs make, both has --keep-going, i just forgot to re-enable it since i move to make :P | 20:20 |
| fta | +se +d, grr | 20:20 |
| === jmc93739653_ is now known as jmc93739653 | ||
| === jmc93739653 is now known as jmc93739653_ | ||
| === bizkut-miau is now known as bizkut-redhat | ||
| mturquette | i see on https://wiki.ubuntu.com/ARM that "Kernels are planned for omap targets". Who is working on that? I'd like to see what progress is made and how I can help. | 21:36 |
| Martyn | mturquette : Actually, that is for the omap4 | 21:40 |
| Martyn | once it's comes out .. | 21:40 |
| Martyn | *thinks* | 21:40 |
| * ojn looks to his right | 21:40 | |
| Martyn | well, for lucid any armv7 ... | 21:40 |
| ojn | got one right here. :) | 21:40 |
| Martyn | ojn : So do I.. but that's not general availability yet :) | 21:41 |
| mturquette | I'm employed by TI, so getting an OMAP4 board is possible. | 21:41 |
| Martyn | ojn : That said though, even smooth-stone should have a processor out by the time general availability of the omap4 is there | 21:41 |
| Martyn | which is all kinds of yay :) | 21:41 |
| mturquette | and I want Ubuntu to rock on OMAP, so I'm trying to find out who to talk to ;-) | 21:41 |
| Martyn | Well, you're certainly in the right place. | 21:42 |
| ojn | mturquette: the basic work isn't that bad. Doing a kernel package is the easy part. DSP packaging, drivers, 3D accel X server, etc, is the more complicated parts. And none of the other supported platforms do that yet either. | 21:43 |
| mturquette | interesting to know. | 21:43 |
| mturquette | i'm basically interested in two things: | 21:44 |
| mturquette | 1) how hard/much time is it to get the base armv7a packages for lucid working on OMAP (I assume that maybe the RootfsFromScratch wiki page should make that quite easy) | 21:44 |
| mturquette | 2) how can I help get support for our accel packages (gles libs for 3D, gstreamer plugins for OMX, etc etc) | 21:45 |
| ojn | mturqutte: 1) is easy. That's what we're doing (Agnilux). It's trivial (rootstock + SD card or NFS root is my preference). Base system works out of the box, comes up with X, etc. | 21:45 |
| ojn | mturquette: on the other packages, working on making deb packages to wrap them up in is a good start. That way you could even distribute them on your own on top of the distro, even if they don't get picked up by official ubuntu. There's a ton of resources out there on how to make debian/ubuntu packages, and this should be a decent place to ask questions about it as well. | 21:49 |
| mturquette | sure, i've done dpkg's before. i'm interested in what process is necessary to get them adopted by Ubuntu. | 21:50 |
| armin76 | mturquette: i want a board *g* | 21:50 |
| mturquette | haha. you're barking up the wrong tree. | 21:52 |
| mturquette | *i* still have to beg for hardware and I work for the damned place! | 21:52 |
| ojn | mturquette: good question. I suppose that requires answers from some of the canonical folks on here, of all seem to be quiet. lool, asac? Not sure who handles what. | 21:56 |
| asac | mturquette: who are you working for? | 22:02 |
| armin76 | asac: TI | 22:03 |
| asac | heh | 22:03 |
| asac | ok | 22:03 |
| armin76 | not interested? :P | 22:03 |
| asac | why not ;) | 22:04 |
| asac | so he wants to recompile everything? | 22:04 |
| asac | or just produce a custom rootfs? | 22:04 |
| asac | mturquette: ? | 22:04 |
| asac | armin76: so its strict-aliasing | 22:05 |
| asac | unpatch that | 22:05 |
| asac | and it will build even on 4.4 | 22:05 |
| armin76 | asac: unpatch what? | 22:05 |
| asac | that chromium sets -fno-strict-aliasing for gcc4.4 | 22:05 |
| asac | one sec | 22:05 |
| asac | http://pastebin.com/f2d00a846 | 22:06 |
| asac | but could be that my build isnt at dtoa yet | 22:07 |
| asac | with all 4.3 it works as that doesnt set it | 22:07 |
| asac | mturquette: for your driver packages, what help do you want? just advice with how to package? | 22:09 |
| asac | third_party/WebKit/WebCore/bindings/v8/DerivedSourcesAllInOne.cpp takes really really long to biuld here ;) | 22:10 |
| mturquette | asac: i'm actually not asking for help. it seems i'm coming to the party a bit late and I just want to know, how *can* I help? | 22:10 |
| asac | heh | 22:11 |
| mturquette | i work for TI, on OMAP, all things Linux, and Ubuntu is important to me as another zealot-type. so basically what has been done, what hasn't? what is blocking you? | 22:11 |
| Martyn | Ahhhh! | 22:12 |
| Martyn | Now I know who you are :) -laugh- | 22:12 |
| Martyn | San Mehat and I were talking about you not that long ago | 22:12 |
| Martyn | (nothing bad! We were just discussing power management in OMAP vs other platforms) | 22:13 |
| * mturquette is concerned by this turn of events. ;-) | 22:13 | |
| asac | fta: no-strict-laiasing is used for gcc_version44=1 in v8 ... unconditionally in WebCore and if no_strict_aliasing=1 is set for the rest of the build | 23:05 |
| asac | feels odd | 23:06 |
| fta | it was initially just a temporary workaround for a crash in v8 snapshot | 23:06 |
| asac | for v8, yes. | 23:06 |
| asac | but what about WebCore ... thats right? | 23:07 |
| fta | but we later discovered other areas where strict aliasing creates bad code | 23:07 |
| fta | with gcc 4.4 | 23:07 |
| fta | some were understood and fixed, others are just obscure, or gcc bugs | 23:08 |
| fta | hence the global no_strict_aliasing=1 i use for gcc 4.4 | 23:08 |
| asac | fta: yeah. so what you definitly dont need anymore is gcc_version44=1 | 23:12 |
| asac | thats auto detected | 23:12 |
| asac | the no_strict_aliasing is not redundant though | 23:12 |
| fta | yes, i know | 23:12 |
| asac | however, thats why i ask | 23:12 |
| asac | why arent the other uses of no-strict-aliasing being made dependent on gcc 44 rather than having two ways | 23:12 |
| asac | and one unconditional way even | 23:12 |
| fta | because some devs want to track those down | 23:13 |
| asac | not sure how that conflicts with making them gcc44 dependent | 23:13 |
| asac | if they are in fact gcc44 dependent | 23:14 |
| asac | if they are not, then that answers my question | 23:14 |
| asac | guess icu is at least needed for 4.3 at least | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
