Linux-atomic you say :) that was just what i fixed with openmpi. Maybe i can help. There are several solutions. I was dead lazy and just sed'ed out the I-have-64bit statement in the internal linux-atomic code in openmpi. Other solution is static compile liblinux-atomic and LD link it to the failing code. Let me find the link i was about to use before i came up with the easier solution.
Can you send me the failing srpm or do you have a git with it somewhere? BR, Bjarne _____________________________ From: Jacco Ligthart <[email protected]<mailto:[email protected]>> Sent: søndag, juni 19, 2016 10:09 AM Subject: Re: [RedSleeve-Users] RSEL 6.8 build progress To: <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]>https://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] https://lists.redsleeve.org/mailman/listinfo/users
