Has anyone been able to successfully build chromium for arm after doing a gclient sync(meaning on the latest source code) ???Can someone please verify this ?
On Tue, Dec 15, 2009 at 11:19 AM, Sofia Tahseen <sofia.tahs...@gmail.com>wrote: > Hi All, > I have not touched sysroot at all. The only thing that I changed was the > GYP_DEFINES and I did the gclient sync. That broke the whole thing. > Does anyone know how I could get back to the old revision of source ? > > Thanks, > Sofia > > On Mon, Dec 14, 2009 at 5:32 PM, Antoine Labour <pi...@chromium.org>wrote: > >> >> >> On Mon, Dec 14, 2009 at 1:30 PM, Sofia Tahseen >> <sofia.tahs...@gmail.com>wrote: >> >>> Hi Antoine/All, >>> >>> This is what I did: >>> export GYP_DEFINES="target_arch=arm >>> sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root >>> disable_nacl=1 use_system_ffmpeg=1" >>> gclient runhooks --force >>> gclient sync >>> >>> export >>> CROSSTOOL=/home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/arm-none-linux-gnueabi >>> export CXX=$CROSSTOOL-g++ >>> export CC=$CROSSTOOL-gcc >>> export AR=$CROSSTOOL-ar >>> export AS=$CROSSTOOL-as >>> export RANLIB=$CROSSTOOL-ranlib >>> export LD=$CROSSTOOL-ld >>> >>> And then I run the make command >>> make -r -j6 BUILDTYPE=Release chrome 2>&1 |tee ./makelog.txt >>> >>> To my suprise, the build is erroring out... I am attaching the makelog >>> for this. >>> Really appreciate your help on this. >>> >>> Thanks, >>> Sofia >>> >> >> The very first target compilation steps fails with missing standard >> headers, which would point at a sysroot problem... >> >> Antoine >> >> >>> >>> On Mon, Dec 14, 2009 at 2:19 PM, Sofia Tahseen >>> <sofia.tahs...@gmail.com>wrote: >>> >>>> Yes it was erroring out at the same point >>>> S32A_Opaque_BlitRow32_neon...but I had not done gclient runhooks >>>> --force...Now I am re-doing it...Lets wait and see how this works. >>>> >>>> >>>> >>>> On Mon, Dec 14, 2009 at 1:07 PM, Erik Corry <erik.co...@gmail.com>wrote: >>>> >>>>> >>>>> >>>>> 2009/12/14 Sofia Tahseen <sofia.tahs...@gmail.com> >>>>> >>>>> Hi Antoine, >>>>>> >>>>>> I did exactly what you said-- not set armv7=1 in gyp_defines. >>>>>> >>>>>> export GYP_DEFINES="target_arch=arm >>>>>> sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root >>>>>> disable_nacl=1 use_system_ffmpeg=1" >>>>>> >>>>>> I rebuilt chromium. >>>>>> >>>>>> And then I reset my kernel so that it does not use NEON. >>>>>> >>>>>> This does not help and the browser keeps crashing again even though I >>>>>> do not set armv7=1 in gyp_defines. So is there a way to disable neon >>>>>> settings on chromium browser and make chromium working on a hardware that >>>>>> does not support NEON? >>>>>> >>>>>> >>>>> Is it still crashing in S32A_Opaque_BlitRow32_neon ? >>>>> >>>>> >>>>>> Thanks, >>>>>> Sofia >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour >>>>>> <pi...@chromium.org>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen < >>>>>>> sofia.tahs...@gmail.com> wrote: >>>>>>> >>>>>>>> Hi Joel/Erik/All, >>>>>>>> >>>>>>>> I don't think armv5 is an issue. Reason being I used the jaunty >>>>>>>> armv5 libraries to build chrome. >>>>>>>> >>>>>>>> I tried to debug the issue with gdb. >>>>>>>> gdb chrome >>>>>>>> GNU gdb 6.8-debian >>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc. >>>>>>>> License GPLv3+: GNU GPL version 3 or later < >>>>>>>> http://gnu.org/licenses/gpl.html> >>>>>>>> This is free software: you are free to change and redistribute it. >>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type "show >>>>>>>> copying" >>>>>>>> and "show warranty" for details. >>>>>>>> This GDB was configured as "arm-linux-gnueabi"... >>>>>>>> >>>>>>>> (gdb) >>>>>>>> (gdb) run >>>>>>>> Starting program: /home/adas/Release/chrome >>>>>>>> [Thread debugging using libthread_db enabled] >>>>>>>> [New Thread 0x4112ac80 (LWP 9722)] >>>>>>>> [New Thread 0x41d49440 (LWP 9727)] >>>>>>>> [New Thread 0x42549440 (LWP 9728)] >>>>>>>> [New Thread 0x42d49440 (LWP 9729)] >>>>>>>> [New Thread 0x43549440 (LWP 9730)] >>>>>>>> [New Thread 0x43d49440 (LWP 9731)] >>>>>>>> [New Thread 0x44549440 (LWP 9732)] >>>>>>>> [New Thread 0x44d49440 (LWP 9733)] >>>>>>>> [New Thread 0x44d69440 (LWP 9734)] >>>>>>>> [New Thread 0x458ff440 (LWP 9738)] >>>>>>>> [New Thread 0x460ff440 (LWP 9739)] >>>>>>>> [Thread 0x460ff440 (LWP 9739) exited] >>>>>>>> >>>>>>>> Program received signal SIGILL, Illegal instruction. >>>>>>>> [Switching to Thread 0x4112ac80 (LWP 9722)] >>>>>>>> 0x0081caec in S32A_Opaque_BlitRow32_neon () >>>>>>>> Current language: auto; currently asm >>>>>>>> >>>>>>>> >>>>>>>> The error S32A_Opaque_BlitRow32_neon () had to do something with the >>>>>>>> floating point setting of the kernel. I checked my kernel >>>>>>>> configuration and >>>>>>>> neon was not set. So I set it and it rebuild my kernel and booted my >>>>>>>> jaunty. >>>>>>>> Now it works perfectly...without any crashes. >>>>>>>> >>>>>>>> Key : In order to run chromium we need to set the neon in the kernel >>>>>>>> configuration. >>>>>>>> >>>>>>> >>>>>>> Note, if you don't set armv7=1 when you build chromium, it shouldn't >>>>>>> use the NEON paths, so you shouldn't run into that problem. But it's >>>>>>> better >>>>>>> to enable it in the kernel if your hardware supports it. >>>>>>> >>>>>>> Antoine >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> Sofia >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry >>>>>>>> <erik.co...@gmail.com>wrote: >>>>>>>> >>>>>>>>> 2009/12/10 Sofia Tahseen <sofia.tahs...@gmail.com>: >>>>>>>>> > You are so right, Joel... I corrected my .so and now I could >>>>>>>>> build the >>>>>>>>> > chrome browser ...finally!! I copied the whole /src/out/Release >>>>>>>>> directory >>>>>>>>> > to my jaunty on the BeagleBoard(256MB RAM). I try to launch >>>>>>>>> chrome through: >>>>>>>>> > ./chrome >>>>>>>>> > It starts up chrome, and then immediately kills chrome. I get an >>>>>>>>> Illegal >>>>>>>>> > Instruction. I restart and I can now see chrome as shown in the >>>>>>>>> attachment >>>>>>>>> > but I cannot browse. When I reload the page, it again kills >>>>>>>>> chrome saying >>>>>>>>> > Illegal instruction. Has anyone seen this before? I have my proxy >>>>>>>>> settings >>>>>>>>> > set too.. >>>>>>>>> >>>>>>>>> This could be anything, but it might be this bug in some versions >>>>>>>>> of >>>>>>>>> gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 >>>>>>>>> >>>>>>>>> If that's it then adding -fno-tree-sink to the flags used for V8 >>>>>>>>> will >>>>>>>>> help. It's a bug that only shows up on ARM and only on some >>>>>>>>> versions >>>>>>>>> of gcc. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > Any help is highly appreciated. >>>>>>>>> > Thanks, >>>>>>>>> > Sofia >>>>>>>>> > >>>>>>>>> > On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley <j...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >> >>>>>>>>> >> On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen < >>>>>>>>> sofia.tahs...@gmail.com> >>>>>>>>> >> wrote: >>>>>>>>> >> >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: >>>>>>>>> >> > skipping incompatible >>>>>>>>> >> > >>>>>>>>> >> > >>>>>>>>> /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so >>>>>>>>> >> > when searching for -lrt >>>>>>>>> >> >>>>>>>>> >> The errors are indicative of trying to link against libraries >>>>>>>>> from a >>>>>>>>> >> different platform. To confirm: check the output of >>>>>>>>> >> >>>>>>>>> >> $ 'file >>>>>>>>> >> >>>>>>>>> /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so >>>>>>>>> >> >>>>>>>>> >> I suspect it will tell you it's a symbolic link to >>>>>>>>> /lib/librt.so.1, >>>>>>>>> >> which itself is a symbolic link to >>>>>>>>> >> /lib/librt-2.10.2.so - note these paths are relative to /, not >>>>>>>>> to your >>>>>>>>> >> sysroot directory. >>>>>>>>> >> >>>>>>>>> >> You have two slightly solutions >>>>>>>>> >> - adjust the symlinks in sys-root/usr/lib so they point to the >>>>>>>>> files >>>>>>>>> >> in sys-root//lib >>>>>>>>> >> - replace the smymlinks with the actual libraries, ie copy >>>>>>>>> files from >>>>>>>>> >> sys-root/lib to sys-root/usr/lib >>>>>>>>> >> >>>>>>>>> >> I would be happy to hear a neater solution for this, but the >>>>>>>>> above >>>>>>>>> >> worked for me. >>>>>>>>> >> >>>>>>>>> >> Cheers, >>>>>>>>> >> >>>>>>>>> >> Joel >>>>>>>>> > >>>>>>>>> > -- >>>>>>>>> > Chromium Developers mailing list: chromium-dev@googlegroups.com >>>>>>>>> > View archives, change email options, or unsubscribe: >>>>>>>>> > http://groups.google.com/group/chromium-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
