Opened 10 years ago

Closed 9 years ago

Last modified 8 years ago

#45712 closed defect (fixed)

xorg-libXt-1.1.4_0 links shared libs with -flat_namespace on Yosemite

Reported by: jhowarth@… Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.3.2
Keywords: Cc:
Port: xorg-libXt

Description (last modified by larryv (Lawrence Velázquez))

% otool -hv /opt/local/lib/libXt.6.dylib
/opt/local/lib/libXt.6.dylib:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64  X86_64        ALL  0x00       DYLIB    17       1872 DYLDLINK NO_REEXPORTED_DYLIBS

reveals that xorg-libXt-1.1.4_0 built on Yosemite is linking its shared libraries with "-flat_namespace" as seen from the missing TWOLEVEL flag expected from "-undefined dynamic_lookup".

Attachments (1)

xorg-libXt.patch (1.5 KB) - added by jeremyhu (Jeremy Huddleston Sequoia) 10 years ago.
xorg-libXt.patch

Download all attachments as: .zip

Change History (29)

comment:1 Changed 10 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added; jeremyhu removed
Description: modified (diff)
Owner: changed from macports-tickets@… to jeremyhu@…

Again with the Libtool MACOSX_DEPLOYMENT_TARGET bug. I’ll prepare a patch in a bit.

comment:2 Changed 10 years ago by larryv (Lawrence Velázquez)

Cc: jeremyhu@… added; larryv@… removed
Owner: changed from jeremyhu@… to larryv@…
Status: newassigned

comment:3 Changed 10 years ago by larryv (Lawrence Velázquez)

Cc: jeremyhu@… removed
Owner: changed from larryv@… to jeremyhu@…
Status: assignednew

Turns out that fixing MACOSX_DEPLOYMENT_TARGET detection doesn’t change the linkage. It appears to be intentional. See configure, line 19172:

case $host_os in
    darwin*)
        OS_CFLAGS="-Wl,-flat_namespace"
	;;
    *)
        OS_CFLAGS=
        ;;
esac

This seems to be an upstream issue, although Jeremy is upstream.

comment:5 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

I have no idea why Ben did that, and I seriously doubt he'd remember if I asked him. If you don't flatten the namespace, what happens?

comment:6 Changed 10 years ago by howarth.at.macports@…

This is the earliest explanation I can find of why -flat_namespace was being used on libXt...

http://lists.apple.com/archives/x11-users/2003/Mar/msg00210.html

Considering this is to solve issues with a libXm from 11 years back that probably bears little resemblance to how the current open motif builds libXm on darwin, I would suggest reverting the change and just watching for regressions from things like nedit or grace that use libXm.

comment:7 Changed 10 years ago by howarth.at.macports@…

If the usage of -flat_namesapce is reverted in xorg-libXt's configure, the change does indeed break motif programs...

% nedit

UTF8 locale not supported.
Error: Shell widget nedit has zero width and/or height

% xmgrace
Warning: Widget must be a VendorShell.
Warning: Fatal Error: 
_XmGetDefaultDisplay cannot be used prior to VendorS.Initialize, returns NULL

Oops! Got SIGSYS

Please use "Help/Comments" to report the bug.
Abort

% molmol

MOLMOL 2K.2 

Version 2.1-2.6: Copyright (c) 1994-98 by
    Institut fuer Molekularbiologie und Biophysik, ETH Zurich
    Spectrospin AG, Faellanden, Switzerland

Version 2K.2: Custom version by Reto Koradi, 1999-2003

using Motif/OpenGL
Warning: Widget must be a VendorShell.
Error: attempt to add non-widget child "dsm" to parent "molmol" which supports only widgets

It might be worthwhile revisting this issue in case there is an actual fix to openmotif for darwin as it seems this hack may exist solely for libXm's benefit.

comment:8 Changed 10 years ago by howarth.at.macports@…

Interestingly, removal of the -flat_namespace in the linkage of libXt cause momol to crash in the same manner as when -lXm isn't placed before -lXt on the linkage...

#18181

So the origin of these crashes are the two name conflicts (_vendorShellWidgetClass, _vendorShellClassRec ) between libXm and the /opt/local/lib/libXt.

Last edited 10 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:9 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Ok, then I suggest we remove the -flat_namesapce from libXt and just audit linkage for this unfortunate collision.

comment:10 Changed 10 years ago by howarth.at.macports@…

Unfortunately removing -flat_namespace is going to nuke anything that uses openmotif. Also, even if we manage to tweak the linkages for packages built against openmotif to not crash, we will break all existing motif based binaries for darwin out there. At the very least, we need to demonstrate that a workaround does exist to allow the macports packages currently using openmotif to keep working.

comment:11 Changed 10 years ago by howarth.at.macports@…

I just checked and molmol links -lXm before -lXt so that doesn't prevent the removal of -flat_namespace from the linkage from breaking the program at runtime.

comment:12 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

What about updating openmotif and lesstif to not provide the symbols themselves but instead re-export the symbols from libXt?

Similar to what is discussed in https://www.mail-archive.com/lesstif@hungry.com/msg01446.html but with better binary compatibility.

Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Attachment: xorg-libXt.patch added

xorg-libXt.patch

comment:13 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Actually no, that re-exporting won't work because libXt's is not acceptable.

comment:14 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

I think the only reasonable thing to do is just fix libXt and make sure that motif dependent projects link in the correct order. As referenced by that link, many other platforms have been having the same issue for quite some time, so I suspect most projects (aside from nedit apparently) link in the expected order.

comment:15 Changed 10 years ago by howarth.at.macports@…

As I said before, these packages are already linking -lXm and -lXt in the correct order and that is insufficient to inhibit the crashes when libXt is rebuilt with -undefined dynamic_lookup

/usr/bin/clang -I/opt/local/include -Os -DBUILD_UNTESTED_NEDIT nedit.o file.o menu.o window.o selection.o search.o undo.o shift.o help.o preferences.o tags.o userCmds.o shell.o regularExp.o macro.o text.o textSel.o textDisp.o textBuf.o textDrag.o server.o highlight.o highlightData.o interpret.o parse.o smartIndent.o regexConvert.o rbTree.o windowTitle.o calltips.o server_common.o rangeset.o linkdate.o ../Microline/XmL/libXmL.a \
	 ../Xlt/libXlt.a ../util/libNUtil.a -bind_at_load -L/opt/local/lib -Wl,-headerpad_max_install_names -lXm -lXp -lXpm -lXext -lXt -lSM -lICE -lX11 -o nedit

/usr/bin/clang -pipe -O1 -arch x86_64 -I.. -I. -I../T1lib/t1lib -I../Xbae -I/opt/local/include -I/opt/local/include main.o plotone.o files.o ssdata.o utils.o drawticks.o nonlfit.o lmdif.o as274c.o fit.o fourier.o graphs.o graphutils.o setutils.o regionutils.o objutils.o computils.o defaults.o params.o draw.o dlmodule.o pars.o missing.o  iofilters.o dates.o t1fonts.o device.o dummydrv.o mfdrv.o mifdrv.o psdrv.o pdfdrv.o svgdrv.o gd.o rstdrv.o humlik.o mathstuff.o Tab.o motifutils.o compwin.o comwin.o eblockwin.o editpwin.o events.o featext.o fileswin.o plotwin.o graphappwin.o helpwin.o hotwin.o locatewin.o miscwin.o monwin.o nonlwin.o printwin.o ptswin.o regionwin.o setwin.o strwin.o setappwin.o tickwin.o worldwin.o fontwin.o xutil.o x11drv.o xmgrace.o -o xmgrace -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -L/opt/local/lib   ../Xbae/Xbae/libXbae.a -lXm -lXpm -lXp -lXmu -lXt -lXext -lX11  -lSM -lICE  ../cephes/libcephes.a   ../T1lib/libt1.a -lpdf -ljpeg -lpng -lz -lm  

/usr/bin/clang -o molmol -I../../tools/include -I../../sg/include -I../../include -DMAXINT=INT_MAX -I/opt/local/include -I../.. -O -Wall MolMol.o MolInit.o ../../lib/libcip.a ../../lib/libcmd.a ../../lib/libui.a ../../lib/libgraph.a ../../lib/libio.a ../../lib/libpu.a ../../lib/libcalc.a ../../lib/libprim.a ../../lib/libdata.a ../../lib/libattr.a ../../lib/libfileio.a ../../lib/libos.a ../../sg/lib/libsg.a ../../tools/lib/libtools.a /opt/local/lib/libtiff.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libpng.dylib /usr/lib/libz.dylib -L/usr/lib -L/opt/local/lib -lX11 -lXm -lGLU -lGL /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib /opt/local/lib/libGLw.dylib -lXmu -lXt -lXp -lXpm -lX11 -lXext -lSM -lICE -lm -lc -lmx

My understanding from those archived discussions is that linkage order is insufficient to work around this issue. So the question becomes, do we want to totally abandon motif by making this change in the absence of any proven breakage from over the last 11 years of using -flat_namespace in this case?

comment:16 Changed 10 years ago by howarth.at.macports@…

My concern is that there still is critical legacy motif software in use. Most NMR users still use NMRDraw (http://spin.niddk.nih.gov/NMRPipe/doc1/figs/tutorial-006.gif) from NMRPipe (http://spin.niddk.nih.gov/NMRPipe/). If you make this change to libXt, all that motif software will be rendered unusable on the Mac once this change makes its way into the next Xquartz release.

Last edited 10 years ago by howarth.at.macports@… (previous) (diff)

comment:17 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

What about just renaming the symbol in lesstif and openmotif and providing a macro to let clients find the new name?

comment:18 in reply to:  17 Changed 10 years ago by howarth.at.macports@…

Replying to jeremyhu@…:

What about just renaming the symbol in lesstif and openmotif and providing a macro to let clients find the new name?

Unfortunately, I think they are tangled up together, If you create a patch that renames all of the instances of VendorShellClassRec and VendorShellRec to OMVendorShellClassRec and OMVendorShellRec, the build of motif fails at...

/bin/sh ../../libtool  --tag=CC   --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/opt/local/lib/X11/bindings\" -DINCDIR=\"/opt/local/include/X11\" -DLIBDIR=\"/opt/local/lib/X11\" -I/opt/local/include  -I/opt/local/include -I/opt/local/include  -pipe -Os -arch x86_64 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include    -MT DragC.lo -MD -MP -MF .deps/DragC.Tpo -c -o DragC.lo DragC.c
libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/opt/local/lib/X11/bindings\" -DINCDIR=\"/opt/local/include/X11\" -DLIBDIR=\"/opt/local/lib/X11\" -I/opt/local/include -I/opt/local/include -I/opt/local/include -pipe -Os -arch x86_64 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include -I/opt/local/include/freetype2 -I/opt/local/include -I/opt/local/include/libpng16 -I/opt/local/include -MT DragC.lo -MD -MP -MF .deps/DragC.Tpo -c DragC.c  -fno-common -DPIC -o .libs/DragC.o
In file included from DragC.c:51:
../Xm/VendorSP.h:48:13: error: unknown type name 'OMVendorShellClassRec'; did you mean 'VendorShellClassRec'?
externalref OMVendorShellClassRec  OMvendorShellClassRec;
            ^~~~~~~~~~~~~~~~~~~~~
            VendorShellClassRec
/opt/local/include/X11/VendorP.h:82:3: note: 'VendorShellClassRec' declared here
} VendorShellClassRec;
  ^
1 error generated.

because the typdef for these two are in coming from the X11 headers...

#ifndef  _XtVendorPrivate_h
#define _XtVendorPrivate_h

#include <X11/Vendor.h>

/* New fields for the VendorShell widget class record */

_XFUNCPROTOBEGIN

typedef struct {
    XtPointer       extension;          /* pointer to extension record      */
} VendorShellClassPart;

typedef struct _VendorShellClassRec {
        CoreClassPart      core_class;
        CompositeClassPart composite_class;
        ShellClassPart  shell_class;
        WMShellClassPart   wm_shell_class;
        VendorShellClassPart vendor_shell_class;
} VendorShellClassRec;

externalref VendorShellClassRec vendorShellClassRec;

/* New fields for the vendor shell widget. */

typedef struct {
        int             vendor_specific;
} VendorShellPart;

typedef  struct {
        CorePart        core;
        CompositePart   composite;
        ShellPart       shell;
        WMShellPart     wm;
        VendorShellPart vendor;
} VendorShellRec, *VendorShellWidget;

_XFUNCPROTOEND

#endif  /* _XtVendorPrivate_h */

If detangling this mess was easy to do, someone would have done it long ago. Note that in the lesstif link you sent me the user proposed renaming and the lesstif developer shot that idea down immediately.

comment:19 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Well then maybe we just fix libXt and create a xorg-libXt-flat-namespace subport which installs to some sub-prefix for the specific use of motif and child projects instead of other libXt clients.

comment:20 Changed 10 years ago by howarth.at.macports@…

What do you plan to do about XQuartz where there is no such option of libXt variants? I am more concerned about the standalone software floating out there which will be broken by such a change.

comment:21 Changed 10 years ago by howarth.at.macports@…

Also if you do move the current flat_namespace version of xorg-libXt into a variant, this should be only done in concert with insuring that port really does honor the Portfile field require_active_variants. Port will need to honor this field so that if...

require_active_variants xorg-libXt flat_namespace

is present in a Portfile it will install the proper xorg-libXt- flat_namespace variant during builds of packages that use openmotif.

comment:22 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

I suggest *NOT* doing a variant becasue we then don't know what we have. I suggest using a subport (so there could be two copies on disk).

comment:23 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Also, it looks like you don't have debug symbols for your MacPorts code. For the relevant ports, I suggest that you set the optimize flags to '-O0 -g3' and build from source with -k. Also, ensure that installed libraries aren't stripped. You should then have dSYMs and source available for the MacPorts libraries

comment:24 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Wrong ticket for that last one, sorry...

comment:25 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed

I gave in and went with the variant approach. I don't have any better suggestions.

comment:26 Changed 8 years ago by EJFielding (Eric Fielding)

After migrating to El Capitan (10.11.6) and reinstalling all my ports, I could not get my Motif programs to run, including "nedit" installed with MacPorts. It turned out that I somehow had the "xorg-libXt @1.1.5_1" port variant active. I just had to activate the "xorg-libXt @1.1.5_1+flat_namespace" variant that was already installed but inactive and now all my Motif programs run. Thought I should describe this here in case someone else has a similar problem.

comment:27 in reply to:  26 Changed 8 years ago by lrebull

I'm running OS 10.11.6, and just updated to XQuartz 2.7.10 this morning. Now I get that same error with nedit: "Error: Shell widget nedit has zero width and/or height".. Sorry to be dense, and I did read everything above .. how did you "activate the "xorg-libXt @1.1.5_1+flat_namespace" variant that was already installed but inactive"??

comment:28 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

sudo port -v -f deactivate xorg-libXt
sudo port -v install xorg-libXt +flat_namespace
Note: See TracTickets for help on using tickets.