> On Sep 8, 2016, at 12:11, Tom Roberts <[email protected]> wrote:
> 
> Ok. Thanks. I'll try copying libXt.6.dylib from 2.7.8 into my build tree for 
> Darwin, then install XQuartz 2.7.9 and build, including it in the bundle. I 
> suspect that this might work, and will be much less growth in the bundle.
> 
> I don't know why libXt.6.dylib from 2.7.9 doesn't work for me (if it did, I 
> would have solved this a week ago without asking questions on multiple 
> developer email lists).

I suspect because you are using libXaw as well.

Note that libXt.6.dylib is unchanged between 2.7.8 and 2.7.9.

> 
> Tom Roberts
> 
> 
> On 9/8/16 9/8/16 - 1:28 PM, Jeremy Huddleston Sequoia wrote:
>>> On Sep 8, 2016, at 11:24, Tom Roberts <[email protected]> wrote:
>>> 
>>> Thank you very much. Note that using libXt.6.dylib from 2.7.9 did NOT solve 
>>> my problem.
>>> By downgrading XQuartz to 2.7.8 I am able to build and run my large program 
>>> on El Capitan (so I did not bother with the test program).
>>> 
>>> I look forward to this issue between OpenMotif and XQuartz being resolved. 
>>> I won't be involved, as I know nothing about either (my code uses neither, 
>>> but it uses 3rd-party libraries that use both). This incompatibility is a 
>>> burden, as my application bundle must grow to include all of the X11 
>>> libraries.
>> It shouldn't need to.  Do you have a dependency on libXaw or libXaw3d?  If 
>> so, you can just build your own replacements of those libraries that link 
>> against libXt.6.dylib instead of libXt.7.dylib.
>> 
>> I have some thoughts about improving the fallback case that will require a 
>> bit more manual intervention but will be more reliable and I'll include that 
>> in the next release when I get some cycles to put out an rc1.
>> 
>>> Tom Roberts
>>> 
>>> On 9/8/16 9/8/16 - 2:47 AM, Jeremy Huddleston Sequoia wrote:
>>>> Yes, openmotif is buggy here and needs to be fixed.  libXt used to build 
>>>> with -flat_namespace in order to support buggy coding paradigms used by 
>>>> OpenMotif and libXaw.  libXt was fixed to use proper namspacing and libXaw 
>>>> and libXaw3d were updated as well to not require that buggy hack (eg: 
>>>> https://cgit.freedesktop.org/xorg/lib/libXaw/commit/?id=b3049d9b13333c0e67f1f23959227020741f486b
>>>> ).  Openmotif needs to follow suit with a similar change.
>>>> 
>>>> 
>>>> Note that XQuartz continues to ship libXt.6.dylib built with 
>>>> -Wl,-flat_namespace in order to maintain binary compatibility with 
>>>> existing openmotif binaries.  The 2-level-namespace version was shipped as 
>>>> libXt.7.dylib.  Unfortunately, executables that make use of openmotif and 
>>>> libXaw sometimes don't work at all because they pull in both versions of 
>>>> libXt and end up with library cross-talk.  I really regret that wasn't 
>>>> discovered in the months of beta and rc testing in which this change was 
>>>> available.  Had it been known before release, I probably would've scrapped 
>>>> the version bump and stayed with a single libXt version (the one with the 
>>>> 2-level namespace), informing OpenMotif users to stay on an older version 
>>>> of XQuartz until OpenMotif released a fix.
>>>> 
>>>> This was discussed in IRC back in January (see
>>>> https://echelog.com/logs/browse/macports/1452121200
>>>> ) and do some other google searches for vendorShellClassRec and 
>>>> vendorShellWidgetClass.  Here's a snippit of that conversation that is 
>>>> relevant:
>>>> 
>>>> [08:32:38] <jeremyhu_> howarth: FWIW, you should spend your effort trying 
>>>> to fix openmotif instead.
>>>> [08:32:41] <howarth> doesn't force the replacement of the existing tcl/tk 
>>>> ports that are installed when building pymol
>>>> [08:32:59] <jeremyhu_> See
>>>> 
>>>> http://pastebin.com/vdaq1gwD
>>>> 
>>>> as a suggested starting point.  It looks like it needs additional work 
>>>> though because nedit doesn't launch with it.
>>>> [08:35:45] <jeremyhu_> howarth: A quick look through looks like there are 
>>>> a bunch of vendorShellClassRec references that I need to get pointed at 
>>>> _XmVendorShellClassRec instead.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Sep 7, 2016, at 14:37, Tom Roberts <[email protected]>
>>>>>  wrote:
>>>>> 
>>>>> This is Mac OS X 10.11.6 (El Capitan) with XQuartz 2.7.9. I installed 
>>>>> OpenMotif 2.3.4 using HomeBrew (so it's in /usr/local). I have a very 
>>>>> large program that uses Motif, which fails now, but worked when built on 
>>>>> Mavericks with an older XQuartz; I traced its problem to Motif, and 
>>>>> Motif's problem seems to be related to libXt.
>>>>> 
>>>>> I found a simple Motif example here (attached, after fixing two trivial 
>>>>> warnings in this old code)
>>>>>    https://www.cs.cf.ac.uk/Dave/X_lecture/node5.html
>>>>> 
>>>>> 
>>>>> It builds in the usual way:
>>>>>    gcc  -I/usr/local/include  -I/opt/X11/include  push.c  
>>>>> /usr/local/lib/libXm.dylib  \
>>>>>           /opt/X11/lib/libXt.dylib
>>>>> 
>>>>> But it does not run, with an error similar to my large program:
>>>>>    a.out
>>>>>    Error: attempt to add non-widget child "dsm" to parent "a.out" which 
>>>>> supports only widgets
>>>>> 
>>>>> BTW I have also seen these error messages from my large program when 
>>>>> trying different combinations:
>>>>>    Error: Couldn't find per display information
>>>>>    Warning: XmManager ClassInitialize: XmeTraitSet failed
>>>>>    Error: attempt to add non-widget child "DropSiteManager" to parent 
>>>>> "main" which \
>>>>>            supports only widgets
>>>>>    _XmGetDefaultDisplay cannot be used prior to VendorS.Initialize, 
>>>>> returns NULL
>>>>>            (I believe this last is from incorrectly linking libXt before 
>>>>> libXm.)
>>>>> 
>>>>> In desperation I went back to the old versions of libXm and libXt (that 
>>>>> work in my large program, built on Mavericks and runs now on El Capitan; 
>>>>> libXm.2.dylib came from its bundle):
>>>>>    gcc -I/usr/local/include -I/opt/X11/include push.c 
>>>>> /usr/local/lib/libXm.2.dylib \
>>>>>          /opt/X11/lib/libXt.6.dylib
>>>>>    a.out
>>>>>    Warning: Cannot find callback list in XtAddCallback
>>>>> A window pops up with the push button, but pushing the button does not 
>>>>> print the message (as the warning suggests). That's why I suspect the 
>>>>> problem is in XQuartz and not OpenMotif. (It's possible my large program 
>>>>> does not use this feature of libXt.)
>>>>> 
>>>>> Help, please!
>>>>> 
>>>>> (I also have an inquiry in homebrew-discuss with subject "openmotif fails 
>>>>> to run".)
>>>>> <push.c> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> X11-users mailing list      (
>>>>> [email protected]
>>>>> )
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> https://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org
>>>>> 
>>>>> 
>>>>> This email sent to
>>>>> [email protected]
>>>> 
>>>>  _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> X11-users mailing list      (
>>>> [email protected]
>>>> )
>>>> Help/Unsubscribe/Update your Subscription:
>>>> https://lists.apple.com/mailman/options/x11-users/tjrob%40muonsinc.com
>>>> 
>>>> 
>>>> This email sent to
>>>> [email protected]
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> X11-users mailing list      ([email protected])
> Help/Unsubscribe/Update your Subscription: 
> https://lists.apple.com/mailman/options/x11-users/jeremyhu%40freedesktop.org
> 
> This email sent to [email protected]

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription: 
https://lists.apple.com/mailman/options/x11-users/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to