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
