That's indeed wierd. I build on an odroid U3: 3.8.13.30 #1 SMP PREEMPT Fri Sep 4 23:45:57 BRT 2015 armv7l armv7l armv7l GNU/Linux
maybe because of the older kernel? still wierd, because I thought the issue was gcc related. hmm, now I think of it, I probably use a different gcc, the 6.8 one in stead of the 6.7 one you use. OK I'll go and test two things: build the latest libreoffice against 6.7 and build it also on a rpi3, with a newer kernel (4.1.19) I'll let you know. Jacco On 06/26/2016 09:39 PM, Bjarne Saltbæk wrote: > > Hi Jacco. > > > Weird (after some days...) my Odroic C+ finished building > libreoffice-4.3.7.2-2.el6.src.rpm without any issues on RSEL6. > > Are you compiling yours on a pure armv5tel? My uname on Odroid C+ says > - Linux odroidc1plus 3.10.96 #1 SMP PREEMPT Fri Jun 3 20:13:29 UTC > 2016 armv7l armv7l armv7l GNU/Linux. > > BR, > > Bjarne > > > On 19-06-2016 10:09, Jacco Ligthart wrote: >> Hi, >> >> I fixed most of the issues below. I think I'm at the point that I >> need other people to also look at it. >> >> @Gordan, if you could sync please? >> >> The one (two?) open issue is that X stops working when updating >> either pixman or xorg-x11-server-Xorg. >> >> This is probably similar to what we've seen earlier, but I still >> don't know what causes this, or how to resolve. >> >> Just remembered, another open issue is that libreoffice won't build >> any more. apparently it now needs a newer gcc or at least a newer >> linux-atomic to build successfully. >> not sure how that is incorporated easiest in the quite complex >> building setup of libreoffice. >> >> Jacco >> >> >> >> >> On 05/20/16 13:56, Jacco Ligthart wrote: >>> Hi, >>> >>> Here an update of the progress of building RSEL6.8 >>> In total there were 308 updated SRPMs and 15 new. Of those 323 I've >>> got now 218 builded without change and 33 with patches. >>> The remaining 72 SRPMs break down as follows: >>> >>> * 62 missing deps (these depend on the issues below) >>> * 4 'known' build errors (an older version build, but the latest not) >>> * 6 new build errors >>> >>> >>> On top of this, I now finally got java-1.8.0 to build, but alas not >>> the latest version. >>> >>> The packages with new errors are: >>> >>> * certmonger (the tests fail, apparently a known issue, I saw a >>> hint that CentOS also had an issue here. I need to look at how >>> they fixed this) >>> * evince (libtool issue, see below) >>> * java-1.6.0-openjdk (the latest security patch breaks the arm32 >>> JIT, not sure how to build without. java-1.8.0-openjdk has a >>> similar issue) >>> * junit4 (java6 Zero VM crashes during build, I've see this >>> before. I'll try if it builds with an older java6.) >>> * mesa-private-llvm (see below) >>> * openssl (tests fail because certificates in the SRPM are now >>> expired, see https://bugzilla.redhat.com/show_bug.cgi?id=1335097) >>> >>> >>> There are two issues I like to expand on as I don not yet know how >>> to properly solve: evince and mesa-private-llvm. >>> >>> _evince_ >>> evince breaks with the following error: >>> g++: >>> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/../../../crti.o: No >>> such file or directory >>> g++: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/crtbeginS.o: >>> No such file or directory >>> g++: /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/crtendS.o: No >>> such file or directory >>> g++: >>> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/../../../crtn.o: No >>> such file or directory >>> >>> On inspection there is no directory 4.4.5, there is one called 4.4.4 >>> and one link named 4.4.7 to the 4.4.4 >>> $ ll /usr/lib/gcc/armv5tel-redhat-linux-gnueabi >>> total 4 >>> drwxr-xr-x 3 root root 4096 Feb 5 01:28 4.4.4 >>> lrwxrwxrwx 1 root root 5 Feb 5 01:28 4.4.7 -> 4.4.4 >>> >>> The 4.4.5 is something that is hardcoded in /usr/bin/libtool, but >>> does not exist any more. I guess that libtool was build when we had >>> a gcc version 4.4.5, while it should have been build with a gcc >>> version 4.4.4 >>> >>> possible solutions: >>> >>> * add a link in the buildroot when building evince and be done >>> with it. >>> * rebuild libtool with a minor version increase, so that it will >>> have a hardcoded reference to 4.4.7 >>> * patch libtool to have a hardcoded link to 4.4.4 >>> * probably more ... >>> >>> Any ideas on the 'correct' fix? >>> >>> >>> _mesa-private-llvm_ >>> This is the most important issue, as mesa depends on this and most >>> of the other missing dependencies are on mesa. >>> >>> mesa-private-llvm breaks with the following error: >>> /usr/bin/ld: >>> /builddir/build/BUILD/llvm-3.6.2.src/Release/lib/libLLVM-3.6-mesa.so: >>> hidden symbol `_ZNSt13__future_base11_State_base15_M_run_deferredEv' >>> isn't defined >>> /usr/bin/ld: final link failed: Nonrepresentable section on output >>> collect2: error: ld returned 1 exit status >>> >>> (as background, mesa and mesa-private-llvm need a newer gcc to >>> build, therefore the SRPM also contains the source of that newer gcc) >>> >>> I have been searching for the mentioned symbol and found that it >>> *is* present in libstdc++_nonshared.a of the new gcc, but if I >>> conduct the same search on a Centos6.7+CR machine, the symbol is >>> also found in libstdc++.a >>> >>> I have not found yet why there are differences of those symbols >>> between armv5 and x86_64. >>> >>> Any help and/or ideas on how to fix appreciated, I'm a bit lost here. >>> >>> Jacco >>> >>> PS, @gordan, all the intermediate work is at the usual place. >>> >>> >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> https://lists.redsleeve.org/mailman/listinfo/users >> >> >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> https://lists.redsleeve.org/mailman/listinfo/users > > > > _______________________________________________ > users mailing list > [email protected] > https://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
