#572 Compare build and runtime Motifs

release
open
nobody
5
2006-11-26
2006-11-26
Andrew Hood
No

In a couple of responses to bug item #1572838:
1. An anonymous poster suggested remembering that you had been warned before, and
2. Thorsten asked if I would make this a separate item.

The attached patch does both of those.

If you are building NEdit with a statically linked Motif, there is of course no way they could not match. However it will still provide reporting of the runtime version in the version outputs.

I have not included the necessary addition of -DHAVE__XMVERSIONSTRING to the Makefiles because I can not test all the supported systems. The comments in each of the system specific makefiles already says what needs to be done.

I know _XmVersionString exists in OpenMotif from 2.1.30 and in all Solaris from 2.6 and AIX from 4.3.3. Earlier versions may work too.

Discussion

<< < 1 2 (Page 2 of 2)
  • Thorsten Haude
    Thorsten Haude
    2006-11-29

    Logged In: YES
    user_id=119143
    Originator: NO

    If we do any comparison, we should also print out a message to stderr if we find a Motif without _XmVersionString. This might come in handy later.

     
  • Andrew Hood
    Andrew Hood
    2006-11-29

    Logged In: YES
    user_id=36856
    Originator: YES

    New version of the patch includes putting warnings in stderr, and more detail in the dialog.

    Re Thorsten's comments:
    If _XmVersionString is not exported from libXm on the compile system nedit will not link. That is why I have always used a compiler option to use this symbol.
    If _XmVersionString was exported on the compile system but is not on the runtime system nedit will not load and you'll get error messages in stderr.
    It is exported on those *tifs that matter, LessTif and OpenMotif.
    It could be done using dynamic loading but that is totally non-portable. e.g. #include <dlfcn.h>

    Re nobody's comments:
    It costs close to nothing to test in those cases where *tif causes problems.
    It costs us time responding to people who say NEdit does not work and the cause is tracked back to problematic versions of their *tif libraries.
    Grace - http://plasma-gate.weizmann.ac.il/Grace/ - has similar tests, so we are not the only ones to see libXm problems.

     
  • Tony Balinski
    Tony Balinski
    2006-11-30

    Logged In: YES
    user_id=618141
    Originator: NO

    I haven't tried the patch yet, but I agree with Andrew here. I credit NEdit users with being able to work out that the dialog tells them something useful in a reasonably unobtrusive way (since you can turn it off).

    Since the normal usage pain is very low, as long as we get the dialog text right, people can carry on using NEdit as before, but are forewarned if problems do occur. It would be good if a level of confidence could be given for the version used itself, but that would mean integrating checktiff into nedit: probably overkill.

    Having a more complete explanation of the consequences of mismatch in the help is a good idea, if only because the help information can also be on the web site. The stderr messages, and -version text, should include the URL anyway.

     
<< < 1 2 (Page 2 of 2)