Building on conda forge OSX fails about mdsplus HOT 12 OPEN

Mention @wdeshazer @ModestMC .

from mdsplus.

This is lower priority than #2731

from mdsplus.

Jumping in to say that resolution of this PR is currently required to unblock several other projects relating to Aurora, which is connected to omfit_classes, which is connected to MDSplus. Efforts to bring this higher in priority are appreciated.

from mdsplus.

Hi @fsciortino and @smithsp,

The fix for Issue #2731 (namely PR #2740) should be released in a few days. Whereupon this issue becomes the top priority.

NOTE: -- MDSplus for Mac presently only compiles on computers that use Intel CPUs. The port of MDSplus to the Apple Silicon computers is underway but has not yet been completed.

from mdsplus.

Hi @smithsp,

I just noticed that this bug report states alpha_7.139.65. However, the GA branch for Atlas is based on alpha_7.139.59. Which version should be used for this Conda Forge fix? (Stated another way, how many versions of MDSplus will GA be using?)

from mdsplus.

@mwinkel-dev The conda-forge builds are mainly used for a robust python package of MDSplus, including for OMFIT and toksearch. They are separate from our other atlas and omega builds. The fix for the conda-forge build can be built off of the usual alpha branch and merged back into the alpha branch. I think the fix should be as easy as putting a #include <_pthread_port> (or similar) in the appropriate file. I wondered if @WhoBrokeTheBuild also might chime in, and I know that there is a new build method to be released at some point that may resolve this type of issue.

from mdsplus.

(You actually responded while we were typing this, which is pretty funny)

@santorofer and I attempted to replicate this in a local environment with miniforge3, the steps from your build.sh and versions matching (as well as we could manage). However, we weren't able to replicate it, and the build succeeded anyway.
I've poured over the azure build log for differences, but wasn't able to find any, so I'm not sure how to replicate it to test a fix.
That being said, I agree with you that including pthread_port.h should fix this issue, if you want to include that in a patch and let us know how it goes, we would definitely appreciate it.
I don't think the new cmake build system will change this, it tries to replicate the compiler flags from the autotools build system as close as possible.

Any ideas you have to help us replicate it or do further testing are also welcome.

from mdsplus.

@WhoBrokeTheBuild I agree that I can't reproduce the issue locally. I think it has to do with the Xcode developer tools available to the conda-forge build bots, which has something to do with redistribution rights. Do you think the pthread_port include belongs in _mdsshr.h or mdsmsg.h or MdsEvents.c?

from mdsplus.

I would put it in mdsmsg.h, since it has the macro that calls clock_gettime, that should cover all the bases

from mdsplus.

Hi @smithsp,

I'm curious whether including the pthread_port.h in the mdsmsg.h fixed the problem that GA encountered with the Conda Forge build of MDSplus for Intel MacOS.

conda-forge/mdsplus-feedstock#54

from mdsplus.

@mwinkel-dev I haven't had time yet to try. I have to inject it via a patch to the source, push it, then wait for the build, which is a little cumbersome, since we haven't figured out how to reproduce the problem on a local build.

from mdsplus.

Hi @smithsp -- Thanks for the update. I will therefore keep this issue open. When you report success with the Conda Forge build, then we will close this issue.

from mdsplus.