On Sat Dec 08, 2018 at 09:11:10PM +0000, Stuart Henderson wrote: > +cc boost co-maintainers > > On 2018/12/04 11:34, Otto Moerbeek wrote: > > On Sat, Dec 01, 2018 at 08:16:33PM +0100, Otto Moerbeek wrote: > > > > > On Fri, Nov 30, 2018 at 01:06:18PM +0000, Stuart Henderson wrote: > > > > > > > On 2018/11/30 13:53, Otto Moerbeek wrote: > > > > > No luck on i386 so far. sp;arc64 ios also not going to work, since the > > > > > boost context lib has no sparc64 support at al. In the meantime I'm > > > > > building arm boost, but that takes ages, it;s now building the > > > > > gcc-4.9.4 port needed by some boost dependency... > > > > > > > > > > Can the impact analysis be done on amd64? > > > > > > > > It can, but not by me, the only bulk building environment I have is > > > > i386. > > > > If there's someone who can do a test bulk build with the diff and run > > > > this under script(1) and send me the output (there will be a lot as we > > > > haven't done a WANTLIB sync for ages) I'll look over it .. > > > > > > > > cd /usr/ports/packages/amd64/all > > > > /usr/ports/infrastructure/bin/check-lib-depends -d . -q -x ./* > > > > > > > > > > Ib the meantime I built patched boost on arm, and tests work out fine > > > (including pdns_recusror). > > > > > > -Otto > > > > > > > The status so far: > > > > amd64: boost context is working fine > > > > i386: only working with a very simple test program, anything using fp > > crashes > > > > arm: working fine. > > > > aarch64: after getting boost to build by skipping the numpy dependency > > (which does not build since there is no gcc 4.9 which is > > required to build fortran dependencies) it also works. > > > > So all in all I think boost context can be enabled for amd64 and arm > > at this moment, provided it does not break anything else. For that I > > need the report sthen@ described above. Any takers? > > > > If the above report looks good I'll submit a full diff, converting all stack > > allocaters to use the proper mmap flag and enabling context only for > > amd64 and arm. We can look at aarch64 and i386 later. > > > > -Otto > > > > Thanks to core developer ajacoutot@ ;) for the bulk build which is > looking good (no failures, nothing unintended picking up the new > libraries in a check-lib-depends run). > > Here's a modified version of Otto's diff. Rather than using PFRAG.<arch> > files I've adjusted it to split the new libraries off to a subpackage > built only on the relevant architectures; this needs REVISION bumps in > dependent ports (which I can handle), that way ports requiring these > libraries (e.g. powerdns recursor when ready) can just depend on the > subpackage, and keep the machine-dependent parts in one place (boost). > > Any comments? Does this seem like the right approach? We could use > selective included PFRAG files and a single package instead but as I see > it the only advantage is not having to bump dep's. > > > :| OK, so here's my diffs to be processed further. It contains the i386 > :| assembly stuff, the stack allocation changes and also a diff to the b2 > :| build process to make it not consume 100% cpu. That's an ugly diff, > :| but I didn't find the actual cause of the zero timeout to the poll() > :| call yet. > > (The latter-mentioned diff is the select_timeout patch.) > >
I'm fine with a subpackage I guess that approach is much more bulk-build friendly but this decision is up to the bulk-core-team. Anyway, thank you very much for working on this topic. If bulk is green ok rsadowski@ Rafael Sadowski
