Monthly Archives: October 2016

XQuartz 2.7.10 and libXt / Motif / IDL

Posted on by

Something of an obscure one here, but documented in case anyone else finds this useful.

XQuartz 2.7.10 introduces changes to the Xt library which can have a significant impact on older Motif applications. In IDL, for example, using the dialog_pickfile() function leads to an instant crash with an error message:

IDL> file=dialog_pickfile()
Warning: Dialog style must be XmDIALOG_MODELESS.
Error: attempt to add non-widget child "dsm" to parent "idl" which supports only widgets

This will probably affect any application built expecting the older version of XQuartz – so while IDL users were the first to notice this I imagine others will have the same problem sooner or later.

The solution (aside from filing bug reports against Motif) is to edit the DYLD_LIBRARY_PATH environment variable so that it includes the directory /opt/X11/lib/flat_namespace/

In the specific case of IDL, the idl startup script (/Applications/exelis/idl/bin/idl) contains a section which amends that variable. It’s an sh script, so if your shell is bash then it should pick up your edits. However many IDL users are also SSWIDL users, and they usually have their shell set to tcsh. In that case it’s probably simplest to edit the ‘idl’ script as follows, around line 245:

if [ "$DYLD_LIBRARY_PATH" = "" ]; then
    DYLD_LIBRARY_PATH="/opt/X11/lib/flat_namespace:$BIN_DIR"
    #DYLD_LIBRARY_PATH="$BIN_DIR"
else
    DYLD_LIBRARY_PATH="/opt/X11/lib/flat_namespace:$BIN_DIR:$DYLD_LIBRARY_PATH"
    #DYLD_LIBRARY_PATH="$BIN_DIR:$DYLD_LIBRARY_PATH"
fi

I’ve left the original lines there, but commented out. Also be aware that the lines above may wrap here but should be left complete in the actual file!

Obviously you should make a backup copy of the original ‘idl’ script before doing this; you’ll probably need to run this as root due to file permissions, hence ‘sudo nano’ will be your friend.

For people on the Maths & Physics munki server I will push out an updated script via Managed Software Center.

Update – apparently some people use the IDLDE environment, and the fix above doesn’t fix that. There is another edit to make to the ‘idl’ script, just past the change above:

if [ "$APPLICATION" = "idlde" ]; then
    # add bindir for idlde shareable libraries
    #DYLD_LIBRARY_PATH="$BIN_DIR_IDLDE:$DYLD_LIBRARY_PATH"
    DYLD_LIBRARY_PATH="/opt/X11/lib/flat_namespace:$BIN_DIR_IDLDE:$DYLD_LIBRARY_PATH"
    IDL_START_DIR_DARWIN=`pwd`
    export IDL_START_DIR_DARWIN
fi

For MSC users this is included in v1.1 of the patch.

I have been in contact with Harris tech support – at the moment they suggest rolling back to XQuartz 2.7.9 but so far as I can tell the changes detailed above are an acceptable workaround, and I prefer to keep current for security reasons.

Update 2 – Harris tech support article which now says basically the same thing!

 

Chrome can’t connect to google.com – irony overload detected

Posted on by

An interesting problem started to pop up for Chrome users starting on Friday 14th – Chrome was unable to connect to any Google website. Other browsers were fine, but Chrome was having none of it.

A recent update to Chrome seems to be favouring the use of Google’s new QUIC protocol to connect to their servers, rather than HTTP(S). At the moment QUIC is blocked at the campus firewall so this doesn’t work, but Chrome doesn’t seem to want to give up, and decides that if it can’t have QUIC then you’re getting nothing.

At the moment the only way to fix things is to block the use of QUIC. Open a new Chrome tab, and enter the address:

chrome://flags/#enable-quic

and change the popup menu from ‘Default‘ to ‘Disabled‘. Chrome will then ask to restart and once that’s done all should be well again.

Screenshot of Google Chrome QUIC settings

 

Update – 19th Oct – Networks are aware of the issue and working to enable QUIC through the firewall. The issue has been replicated on a lot of Macs and also Windows 10 systems.

Update 2 – 19th Oct – Even with the firewall allowing QUIC to pass through it seems that Chrome v54 – which started auto-deployment last week – has a bug which triggers this issue. There similar reports on the Chrome releases blog. We may have to wait for Google to fix this! Chrome v53 seems to behave properly – either using QUIC or else falling back to HTTPS as it should.

Update 3 – 21st Oct – Chrome 54.0.2840.71 has been released which appears to fix this problem! If you disabled QUIC I don’t see much to gain by re-enabling unless you’re feeling keen.

Sierra printing ‘anomaly’

Posted on by

I installed Sierra on my Mac today as there didn’t seem to be any major known issues affecting my configuration, and I had updated all my core apps to Sierra compliant versions. So far I’ve found one anomaly.

When printing to the MFDs I keep getting prompted for my AD credentials. My Mac isn’t bound to the AD, but in pervious versions of OS X when I had entered my staff number and password, and selected to store them in the Keychain, I would never be prompted for them again. Printing ‘just worked’. On Sierra I get the prompt for credentials each time; the dialog is pre-filled with the correct data so all I need to do is hit enter or click OK, but it’s annoying!

I have tested this on various machines, both upgrades to Sierra and fresh installs, and on new and upgraded user accounts. All show the same behaviour. It seems the same as discussed on this thread in Apple Discussions. I don’t think this is a change for the better, so I have lodged a bug report with Apple.

Update 16 December 2016 – Apple has addressed this issue with macOS 10.12.2 by adding a preference to revert to the previous behaviour.