On Thu, 20 Dec 2018, Vineet Gupta wrote: > On 12/18/18 1:04 PM, Vineet Gupta wrote: > > (a) build-many-glibcs.py check results are clean > > > > | Summary of test results: > > | 1173 PASS > > | 15 XFAIL > > | > > | PASS: glibcs-arc-linux-gnu check > > One of the issues in running build-many incrementally, i.e. "host-libraries", > "compilers" only once but "glibcs" again to quickly test fixes is that for 2nd > run, target c++ compiler is picked up for support/links-dso-program vs. > links-dso-program-c which fails as the cpp headers are not present. Is there a > solution to that ? I'm not aware of that problem. The C++ headers certainly should be available in the compilers installed by the "compilers" step. My bots using GCC 7 and 8 branches only rebuild the compilers once a week unless build-many-glibcs.py itself changes. > One of the pesky issues with cross testing is localedata/gen-locale.sh > kicking on target, which despite being 1GHz gets in the way of quick > iterations. Is there a way to build those on host and simply > reference/install them on target. I understand this is more of a > buildsystem question (buildroot), but any pointers would be appreciated. It's possible to set up an external build system that extracts the list of locales for testing from localedata/Makefile, builds them using the same version of localedef built for the build system and appropriate options for endianness and uint32_t alignment (if necessary) and copies them into the right places in the glibc build tree before running the glibc tests. It does have to be the same version of localedef since the binary locale format can change depending on the glibc version. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
