Le 25/11/2013 15:32, Michal Hrusecky a écrit :
Guillaume Gardet - 11:33 25.11.13 wrote:
Le 25/11/2013 11:14, Guillaume Gardet a écrit :
Le 24/11/2013 21:12, Michal Hrusecky a écrit :
Guillaume Gardet - 11:57 22.11.13 wrote:
Le 22/11/2013 11:47, Michal Hrusecky a écrit :
Guillaume Gardet - 10:13 22.11.13 wrote: > Le 22/11/2013 09:55, Guillaume Gardet a écrit : >> Hi, >> >> Le 22/11/2013 09:12, Michal Hrusecky a écrit : >>> Hi, >>> >>> today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I >>> ended up with invalid instruction errors just after update of glibc. My guess >>> is that glibc was compiled with neon support enabled. Was there any decision to >>> drop non-neon devices or is it simply a bug? Is it just glibc that has neon >>> enabled or everything? I know that for 32bits we have two glibc packages, maybe >>> something similar would be possible for armv7? >>> >> AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC). >> >> All my ARM boards are neon capable so I cannot test. :( >> >> Maybe Alex, or Dirk, could help here? > Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present. > > I am building glibc with multi-arch enabled. > Once built, could you test if it fix your problem? > Sure!
Here is the glibc RPM to test: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-4.6.1.armv7hl.rpm
Not sure it will fix the problem because build log seems to tell multiarch was auto-detected before. But let's try it.
If rpm, yast or zypper cannot install it, extract it on the SD card.
hmmm, tried it, didn't helped, tried 12.3 glibc, that one helped :-/
Will ask upstream.
But could you try a 13.1 JeOS rootfs, please? Just to be sure that things are not working with updated glibc and software built with this one.
Upstream seems to know this problem. See this resolved bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15905
Will try to apply this patch on a locally built glibc and I will send you so that you can test.
Cool, thanks!
Could you try this one, please: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-312.1.armv7hl.rpm
Guillaume