Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Wed, 16 Nov 2016 11:55:20 -0600

On 11/16, Wang Xiaoqiang (PSI) wrote:
> Hi Lewis,
> 
> I just want to report my working setup of MEDM on macOS Sierra, with
> XQuartz 2.7.11.

Hi, Xiaoqiang!

Thank you for your report!

> I have installed openmotif from MacPorts
> $ port installed | grep openmotif
>   openmotif @2.3.4_3 (active)
> 
> The medm (3.1.9) extension is configured like this
> $ cat configure/os/CONFIG_SITE.darwin-x86.darwin-x86
> #
> # DarwinPorts OpenMotif
> #
> X11_LIB=/opt/local/lib
> X11_INC=/opt/local/include
> MOTIF_LIB=/opt/local/lib
> MOTIF_INC=/opt/local/include
> 
> I just tried a “make clean&&make”. That still works.

I suspect that still works because your Motif library (libXm) is using
the X Toolkit Intrinsics library (libXt) from MacPorts, not the one
from XQuartz.  Can you run the following command on your medm binary to
confirm?

--- 8< ---
$ otool -L ./medm
./medm:
	/opt/epics-3.14.12.5/lib/darwin-x86/libca.3.14.12.dylib (compatibility version 3.14.0, current version 3.14.12)
	/opt/epics-3.14.12.5/lib/darwin-x86/libCom.3.14.12.dylib (compatibility version 3.14.0, current version 3.14.12)
	/opt/pkg/lib/libXm.4.dylib (compatibility version 5.0.0, current version 5.4.0)
	/opt/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/X11/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.4.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
--- >8 ---

As you can see, my medm is linked against /opt/X11/lib/libXt.6.dylib
which is provided by XQuartz.  I suspect yours will not be linked
against that one but rather against one from MacPorts.

Looking at the MacPorts Portfile for x11/openmotif, it contains a
depends_lib entry for port:xorg-libXt which means it depends on the
x11/xorg-libXt port.  It also contains this line:

  require_active_variants xorg-libXt flat_namespace

I think that means you would have to specify the flat_namespace
variant for the x11/xorg-libXt port.  And if you've specified
that variant for the x11/xorg-libXt port, then it links with
the flags "-Wl,-flat_namespace" which is probably how XQuartz's
/opt/X11/lib/flat_namespace/libXt.6.dylib was built.

So, I suspect if you did a fresh build of your MacPorts ports and did
not specify the flat_namespace variant for the x11/xorg-libXt port,
it would probably fail to build the x11/openmotif port.  Then if you
added the variant, it would probably succeed.  But libXt would not be
built as a two-level-namespace shared library; it would be built as a
flat-namespace shared library.  You can confirm this by looking for the
TWOLEVEL flag with otool:

--- 8< ---
$ otool -hv /opt/X11/lib/libXt.6.dylib 
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    19       2024   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS APP_EXTENSION_SAFE
$ otool -hv /opt/X11/lib/flat_namespace/libXt.6.dylib 
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    19       2024 DYLDLINK NO_REEXPORTED_DYLIBS APP_EXTENSION_SAFE
--- >8 ---

So, the flat-namespace shared library does not have the TWOLEVEL flag,
whereas the two-level-namespace shared library does.  I think your
MacPorts libXt will not have the TWOLEVEL flag; this means it is a
flat-namespace shared library.  And that should work, but it's similar
to my other workaround of moving the two-level-namespace libXt from
XQuartz out of the way and replacing it with XQuartz's flat-namespace
version.

Regards,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System