[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XForms] XForms failure after upgrading to Fedora 19

From: Jens Thoms Toerring
Subject: Re: [XForms] XForms failure after upgrading to Fedora 19
Date: Sun, 12 Jan 2014 13:49:27 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi David,

On Sat, Jan 11, 2014 at 07:06:07PM -0800, address@hidden wrote:
> I recently upgraded my Linux system to Fedora 19 from Fedora 17 (64 bit OS
> in both cases). All programs seemed to compile and function properly after
> the upgrade, BUT this was not the case - an important program based on
> XForms failed when any user other than myself (I'm system administrator, but
> my id has no special privileges like being a sudoer) used it. It had
> previously worked perfectly in Fedora 17 (Because of some of the operations
> it does it cannot run as root).

And that definitely shouldn't be required!!!

> I investigated this and found that when the
> program reached a fl_do_forms() statement it would flash momentarily on the
> screen and then close.
> I then decided to do a test - I tried a simple program:
> #include <forms.h>
> int main(int argc, char **argv)
> {
>    FL_FORM *form;
>    fl_initialize(&argc, argv, 0, 0, 0);
>    form = fl_bgn_form(FL_UP_BOX, 230, 100);
>    fl_add_button(FL_NORMAL_BUTTON, 20, 20, 190, 60, "Hello world");  
>    fl_end_form();
>    fl_show_form(form, FL_PLACE_MOUSE, FL_FULLBORDER, "Hello, world!");
>    fl_do_forms();
>    fl_hide_form(form);
>    fl_finish();
>    return 0;
> }
> Once again, I found that any user other than myself or root would have that 
> program fail - it would flash onto the screen and then disappear 
> The solution offered by another user was to put a while loop to trap 
> fl_do_forms() :
>    while ((all = fl_do_forms()) != ok)
>       /* empty */ ;
> which works, but is neither a feasible nor a satisfactory solution for my 
> program.
> All programs were compiled using gcc and the 1.0.94-0.9.pre17.fc19.rpm from
> Fedora (although the library appears as libforms.so.2.0.0 in /usr/lib64).

A programs version number and the SO_VERSION rarely are the same,
so this is no reason for concern. The first number in the SO_VERSION
should get bumped up every time a incompatible change is made to
the library, the second one when additions to its interface are
made (but programs linked against an older version will still
work with it) and the last one is for minor changes. In contrast,
program version numbers are basically random numbers - you pick
them as you like, the only common convention is only that higher
numbers indicate "newer" and, hopefully, "better";-)

> The systems all use nVidia graphics cards which have the latest drivers.

Also this shouldn't really matter, XForms doesn't deal with
any low level stuff, that's what X11 is supposed to do, and
XForms "sits" on top of that.

> I'm stumped - any ideas what might be happening?

I'm also stumped. To start with I'm a bit surprised that they
distribute xforms-1.0.94pre17 which is a development release
intehded for people doing testing for the next statble release.
But ok, it should work rather reliably. And it gives me a point
in time when this problem started to appear;-)

To investigate I installed Fedora 20 LXDE (I didn't see any
download candidates for Fedora 19) under VirtualBox on my
machine (installing xforms used 1.0.94-0.10.pre17.fc20.rpm).
But, unfortunately, I can't reproduce the problem. I took
your example program, compiled it and it runs without any
issues as root, as the "standard user" set up during instal-
lation and as well as a completely new user, created some
time after installation. I also tried to run the program
when installed in /usr/bin but, again, nothing out of order.
Also using different compiler flags etc. didn't produce any
other results.

A few days ago I talked with someone who experienced the same
problem (with the new stable xforms release manually installed)
on openSUSE 13.1. Also with this I had no luck reproducing the
problem and he found, after reinstalling openSUSE from scratch
on two of his machines in slightly different ways, that the
problem went away on one and persisted on the other. The only
noticable difference he found between the programs on the two
machines was in the sequence the shared libraries were listed
by ldd. But that could be a red herring. Since he didn't had
any more time for further tests we stopped at that point.

At the moment I have no idea at all what could make fl_do_forms()
behave differently on different machines but with the same OS or,
as in your case, just by being a different user. Obviously,
something must be happening but since I can't reproduce the
problem on any machine I have access to it's very difficult
to even guess what this might be (and if such a guess would
be correct is another question). The first thing I'd do would,
of course, be to check what fl_do_forms() returns when it

May I ask if it would be possible to give me a temporary
account I can log into with ssh on a machine exhibiting
the problem? Since none of my attempts to reproduce it were
successful I have no better idea for how to proceed. Other-
wise any further observations about possible differences
between the accounts could be helpful. For example: do
they use a different window manager from the one you're
                           Best regards, Jens
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de

reply via email to

[Prev in Thread] Current Thread [Next in Thread]