Re: boost diff

On Sun, Nov 25, 2018 at 08:44:17AM +0100, Otto Moerbeek wrote:

> On Sat, Nov 24, 2018 at 12:24:59PM +0000, Stuart Henderson wrote:
>
> > 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.
> >
>
> Hmm, i386 builds but my trivial test program core dumps in
> jump_fcontext(). It looks like the stack context created by
> make_fcontext() isn't right on OpenBSD (or handled incorrectly by
> jump_fcontext()). Pondering now wether to spend time on this. Both
> functions are written in assemby and I never learnt i386 assembly.
>
> -Otto
>
>

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 looks like that's going
to be the only arch on which boost context is known to work for at
least a while.

-Otto