If, like me, you use a Mac and both WSJT-X and JTDX for data modes you may run into a problem I had.
The problem comes about because both applications insert a property list into /Library/LaunchDaemons. These property lists are used by the MacOS to start background processes (or daemons) at system startup. But as far as I can tell there is no defined order in which the daemons are started.
I installed the SDRplay API which as part of the install puts a property list into /Library/LaunchDaemons. This must have affected the order in which MacOS started the daemons because suddenly WSJT-X failed to start with a shared memory error. This error persisted even after a re-install and configure of WSJT-X.
I looked at /Library/LaunchDaemons because as part of the WSJT-X install you put a property list there. Sure enough, JTDX does the same (as it is derived from WSJT-X) and the property lists clash because (at least on my system and my version of JTDX) JTDX makes the shared memory size smaller than WSJT-X likes.
So, I think I was getting away with this before I installed the SDRplay API because the WSJT-X property list was being processed after the JTDX one and the shared memory was made big enough for WSJT-X. But after my SDRplay API install the JTDX property list was being processed after the WSJT-X one and the shared memory size was too small.
I fixed this situation by deleting the JTDX property list com.jtdx.sysctl as it is redundant in this circumstance.
And all is well.