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.
-Otto
