Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#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 1 of 2)
  • Andrew Hood
    Andrew Hood
    2006-11-26

    patch against CVS HEAD 2006-11-26

     
    Attachments
  • Thorsten Haude
    Thorsten Haude
    2006-11-26

    Logged In: YES
    user_id=119143
    Originator: NO

    1. It seems natural to make this check, but I'm not so sure about the dialog. My guess is that most users who would see the dialog have no idea what we are talking about, so a bit more explanation could be handy. Something not too technical, just pointing out possible problems:
    You are trying to run NEdit using differing versions of the motif library at the same time. This (could lead|usually leads) to intermittent errors while using NEdit, so we don't recommend it. Please do not report any bugs you encounter unless you can reproduce them with matched build and runtime.

    If this is too long for the dialog we could put it in a separate help dialog, like the Customize Window Title dialog does.

    2. I expected that the combination of XmVERSION_STRING and _XmVersionString is what should be remembered, not NEdit's $VERSION and _XmVersionString. Why is $VERSION important?

    Minor points:
    - The setting should be called dontWarnDifferengMotif or somesuch, in case we ever want a warning about some other aspect of motif.
    - Maybe a Cancel button should offer a way out for the nervous type.

     
  • Andrew Hood
    Andrew Hood
    2006-11-26

    Logged In: YES
    user_id=36856
    Originator: YES

    1. Consider the number of times we have issues with people using certain versions of LessTif and OpenMotif causing us grief. Warning them that the Motifs don't match, in order to reduce the number of blind alleys we get drawn into, justifies telling them. It's in the version text, but they won't see that without being asked to provide it. They only have to click "Don't tell me again" once.
    2. Matching on both NEdit and *tif versions may be overkill. I would prefer that they get separate warnings from Nedit 5.5 and from 5.6, and so on. The only effect is that the string could grow beyond the length limit. Maybe I should reverse the concatenation and add the new entry at the front of the list. strncat will stop it overrunning.

     
  • Thorsten Haude
    Thorsten Haude
    2006-11-26

    Logged In: YES
    user_id=119143
    Originator: NO

    1. Yeah, I agree with you, my comment was only about the way the dialog is done. I just think that, since this a pretty basic fault in the user's setup, a longer explanation would be better. Otherwise people might just think NEdit won't run on their system and find something else. (Actually, we might emphasize a little more how the problem can be solved.)

    2. I can see why matching $VERSION make sense, but why is it more important than matching XmVERSION_STRING? Maybe I'm missing some piece of knowledge here.

     
  • Andrew Hood
    Andrew Hood
    2006-11-26

    Logged In: YES
    user_id=36856
    Originator: YES

    1. I don't see any point in a Cancel button. We could make OK button "Remind me next time." Any return code other than "Don't warn me again" should be treated as "Remind me next time.". It is not necessarily a fault in their setup. If I compile on one system with 2.2.3 and try to run it on another with 2.1.30 I will get the warning, but the 2.1.30 system is not broken, just not necessarily compatible. What happens if an official shared build uses 2.1.30 and the user has an "approved" LessTif?

    2. XmVERSION_STRING is a #define in Xm/Xm.h so is a compile time value.
    _XmVersionString is defined extern in libXm and is set as the value of XmVERSION_STRING at the time the library was compiled. It is not declared in Xm/Xm.h (a bad decision in my opinion) so you need to determine that it exists in your libXm. e.g.

    : nm /usr/X11R6/lib/libXm.so|grep _XmVersionString
    0019b0c0 D _XmVersionString

    Everything built from OSF based source exports it.

    3. I missed the comment about what to call the setting. dontWarnDifferentMotif sounds reasonable and futureproof.

     
  • Scott Tringali
    Scott Tringali
    2006-11-27

    Logged In: YES
    user_id=11321
    Originator: NO

    I have a few issues with this:

    1) It's probably too overzealous. On most systems besides Linux, they take binary compatablility seriously and this isn't a problem. For example, I remember some (IRIX?) systems have Motif 1.2.3 and other have 1.2.4, and it works fine. We have knowingly taken advantage of this in the past years by building a single binary. We should only do this check on systems that are known to be troublesome.

    Further, it's likely to kill nedit when people do upgrades. Imagine nedit built against a version of lesstif. They do a 'yum update' or whatever to get a new lesstif, and now nedit is dead. Even if the two are compatible.

    2) It's likely this should not use a dialog. If Motif is messed up, then it doesn't seem that using a Motif dialog is a good idea. Case in point: mixing OpenMotif and LessTif. You'll crash hard. It would be better to print this on standard error and exit.

    I suggest something like:

    A) If it's a severe mismatch (LessTif vs. OpenMotif) then printf to stderr and exit. Check this early because any Motif calls are likely to die.

    B) If it's a major mismatch (1.2. vs 2.0), I'm not sure.

    C) If it's a minor mismatch (1.2.3 vs. 1.2.4) then don't complain.

     
  • Thorsten Haude
    Thorsten Haude
    2006-11-27

    Logged In: YES
    user_id=119143
    Originator: NO

    Scott's 1) I think we should do the check everywhere. It's dead cheap and you never know if someone wants to try Lesstif. Also, why should NEdit be dead? You see the dialog, click it away and never think of it again.
    Scott's 2) I agree with you here, it should at least be a message on stderr. I wouldn't mind the dialog though, it might help the user identify any problems, and the console is not always visible.
    (BTW, this is not the first time I wished for a nPrintMessage() which would just pick the best place(s) for messages like this.)

    A) I agree
    B) How about the dialog here?
    C) Only if we are confident that it would work, eg. what you said above about non-Linux OSes.

     
  • Andrew Hood
    Andrew Hood
    2006-11-27

    Logged In: YES
    user_id=36856
    Originator: YES

    Re Scott's comments:

    1) I'll trade a one-time inconvenience to the user for fewer complaints. The dialog does not stop NEdit running. The user would have to choose Quit after they closed it.

    2) If the build and runtime are so incompatible that the dialog crashes, NEdit was going to crash very soon anyway. If the dialog runs, the user can choose to take their chances NEdit won't crash later. Thorsten is right saying stderr is not always visible. If you launch from an icon that is almost certainly true. If you are volunteering to write this dialog as native X code, be my guest.

    I have no issue with calling the code that puts '-version' on stderr before popping the dialog in case it crashes, and putting more text in the dialog. Include the A/B/C suggestions so as to avoid needing to parse the version strings.

    A - It's a severe mismatch (e.g. LessTif vs. OpenMotif) - quit while you're ahead.
    B - Build version < Runtime version (e.g. 1.2.x < 2.1) - is OK if the lib is claimed to be backward compatible. build > runtime is probably not safe.
    C - Build version = Runtime version but patch levels differ (e.g. 1.2.3 vs 1.2.4) - this is probably safe.

    Adding text to the Help will only be of use if the Help dialog will actually run. If you get this far, NEdit will probably run. Possibly not perfectly.

     
  • Thorsten Haude
    Thorsten Haude
    2006-11-27

    Logged In: YES
    user_id=119143
    Originator: NO

    - The one-time inconvenience will possibly also create complaints.
    - I think the X dialog is unneeded. Either Motif runs or the user should use the console.
    - -version should be X-proof. It currently is. Of course the less X you have, the less you can report about X problems.
    - I think C warrants a line in -version.
    - The dialogs help should be independent from the usual help hierarchy, just like the Window Title help.

     
  • Logged In: NO

    As a nedit user I think there is no need to do the check, because

    1) Nedit works fine at most of the time. In a few cases it doesn't, but that's normal.
    2) A check can't check everything. So don't bother.

     
1 2 > >> (Page 1 of 2)