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
