On 2018/11/24 13:20, Otto Moerbeek wrote: > On Sat, Nov 24, 2018 at 12:01:48PM +0000, Stuart Henderson wrote: > > > On 2018/11/24 09:45, Landry Breuil wrote: > > > On Sat, Nov 24, 2018 at 07:54:36AM +0100, Otto Moerbeek wrote: > > > > On Wed, Nov 21, 2018 at 01:19:27PM +0100, Otto Moerbeek wrote: > > > > > > > > > Hi, > > > > > > > > > > I am playing with boost contexts which is configured out by the > > > > > current port. > > > > > I am able to make execution_context and fcontext work on amd64. The > > > > > first > > > > > using a simple test program and the second using a non-trival program. > > > > > > > > > > The only actual change in boost itself is to use a mmap(... > > > > > MMAP_STACK ...) for stack allocation. So I like to enable the > > > > > disabled parts. They are not extensivly tested and some other parts > > > > > might need a patch too (there are several classes creating stacks). > > > > > > > > > > At the moment I just like to know if I am taking the right approach > > > > > port-wise. So, any comments or advise? > > > > > > > > Total silence.... remember I'm a total ports newbie, I really could > > > > use some guidance here. Is this the right approach for a port having > > > > arch specific features and plist? > > > > > > That is the right approach in general, but for a leaf port. Here, lots > > > of other ports depend on boost, and stuff might pick up those new libs > > > on amd64 (or updates/new ports start relying on them), and then the same > > > stuff start breaking in subtle ways on other archs (few ppl cares about). > > > > Yes exactly this... The approach would need to be : > > > > build dependent ports (130-odd, many large/slow) > > > > run "check-lib-depends" on the produced packages, see if the new libraries > > are picked up > > > > if so, add arch-dependent bits to add the relevant libraries to WANTLIB > > > > (and as they're not extensively tested, alert people to the ports which > > have picked this up and request further testing of these) > > > > Additionally we need to watch imports/updates of ports using boost in the > > future to see if they start using these libraries otherwise builds will > > break (it's not so bad if it's amd64-only, but if all the "fast" arches > > gain support, we typically don't discover breakage in this form until > > it's time for release builds when it's too late to fix). > > > > So the question is "is it worth it". Could be - this is a path to running > > some software (pdns-recursor comes to mind) which otherwise won't run on > > OpenBSD because we never got support for the ucontext.h functions .. > > > > pdns-recursor is the cause I'm looking into this. ucontext is not only > deprecated but actually removed by posix, I do not want to go that > road. So boost's fcontext remains and it is working properly on amd64 > at least. > > I could maybe go a more conservative approach and only enable boosts's > context lib. That's all I need, and the scope of potential breakage > will be more limited. > > But first next step is building and basic tests on i386 and sparc64.
If you get i386 working, once we're done with LLD test builds on i386, I can help with bulk builds and WANTLIB checks there.
