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