Bug 186508 - Anjuta displays 3 error dialog boxes during startup.
Anjuta displays 3 error dialog boxes during startup.
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: anjuta (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul F. Johnson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-23 17:55 EST by Bryan Christ
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-03 03:45:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch against anjuta 1.2.4 (540 bytes, patch)
2006-03-24 13:25 EST, Michael Schwendt
no flags Details | Diff
trivial spec changes (857 bytes, patch)
2006-03-24 13:26 EST, Michael Schwendt
no flags Details | Diff

  None (edit)
Description Bryan Christ 2006-03-23 17:55:53 EST
Description of problem:

Anjuta displays 3 error dialog boxes during startup.  As a result of one of
these errors, the file dialog boxes don't work correctly and you are unable to
create new source or header files.  The 3 error messages are:

ERROR: Unable to load plugin /usr/lib/anjuta/libanjuta_clsGen.so.
Error: /usr/lib/anjuta/libanjuta_clsGen.so: undefined symbol: file_is_directory

ERROR: Unable to load plugin /usr/lib/anjuta/libanjuta_sample1.so.
Error: /usr/lib/anjuta/libanjuta_sample1.so: undefined symbol: anjuta_info_show_list

ERROR: Unable to load plugin /usr/lib/anjuta/libanjuta_patch.so.
Error: /usr/lib/anjuta/libanjuta_patch.so: undefined symbol: app

Version-Release number of selected component (if applicable):

anjuta-1.2.4-3.fc5

How reproducible:

Every time


Steps to Reproduce:
1.  Install Fedora Core 5 with default desktop packages.
2.  After install, "yum install anjuta"
3.  Open anjuta.
  
Actual results:


Expected results:


Additional info:
Comment 1 Paul F. Johnson 2006-03-23 18:09:16 EST
Very odd - it's working fine at this end!

I know it say's on the report you're on i386, could you confirm this and also
tell me what is in /usr/lib/anjuta?

On my buildsys (x86_64), the code is built happily into /usr/lib64/anjuta
without a hitch. I've just rpm removed anjuta/anjuta docs, ensured that nowhere
on my machine that /usr/lib*/anjuta existed and then reinstalled and cannot
replicate the problem.

It may therefore be an i386 problem, which may mean the buildsys is naffed!
Comment 2 Bryan Christ 2006-03-23 18:12:54 EST
[root@tuxdev anjuta]# ls
libanjuta_clsGen.so        libanjuta_patch.so        libanjuta_sample1.so
libanjuta_clsGen.so.0      libanjuta_patch.so.0      libanjuta_sample1.so.0
libanjuta_clsGen.so.0.0.0  libanjuta_patch.so.0.0.0  libanjuta_sample1.so.0.0.0
[root@tuxdev anjuta]#
Comment 3 Paul F. Johnson 2006-03-23 18:14:27 EST
I take it that those libs are in /usr/lib/anjuta?

Out of interest, if you run /sbin/ldconfig does that sort the problem?
Comment 4 Bryan Christ 2006-03-23 18:18:37 EST
I just now added /usr/lib/anjuta to ld.so.conf and ran ldconfig to see if that
made the problem go away.  No such luck.  Here is a long listing from
/usr/lib/anjtua

[root@tuxdev anjuta]# ls -l
total 56
lrwxrwxrwx 1 root root    25 Mar 14 17:29 libanjuta_clsGen.so ->
libanjuta_clsGen.so.0.0.0
lrwxrwxrwx 1 root root    25 Mar 14 17:29 libanjuta_clsGen.so.0 ->
libanjuta_clsGen.so.0.0.0
-rwxr-xr-x 1 root root 37828 Feb 22 15:42 libanjuta_clsGen.so.0.0.0
lrwxrwxrwx 1 root root    24 Mar 14 17:29 libanjuta_patch.so ->
libanjuta_patch.so.0.0.0
lrwxrwxrwx 1 root root    24 Mar 14 17:29 libanjuta_patch.so.0 ->
libanjuta_patch.so.0.0.0
-rwxr-xr-x 1 root root 10360 Feb 22 15:42 libanjuta_patch.so.0.0.0
lrwxrwxrwx 1 root root    26 Mar 14 17:29 libanjuta_sample1.so ->
libanjuta_sample1.so.0.0.0
lrwxrwxrwx 1 root root    26 Mar 14 17:29 libanjuta_sample1.so.0 ->
libanjuta_sample1.so.0.0.0
-rwxr-xr-x 1 root root  4044 Feb 22 15:42 libanjuta_sample1.so.0.0.0
[root@tuxdev anjuta]#
Comment 5 Paul F. Johnson 2006-03-23 18:22:00 EST
I take it that those libs are in /usr/lib/anjuta?

Out of interest, if you run /sbin/ldconfig does that sort the problem?
Comment 6 Paul F. Johnson 2006-03-23 18:29:08 EST
Other than the time stamps (mine all report the file the others are ln -s'd from
as being Feb 22 21:43), these are the same.

I've just tried to replicate the problem by moving the .anjuta directory and
restarting, and it still fired up first time without the errors. I'll need to
check to see if there is a difference between the x86 and x86_64 rpms (the
laptop is i386, but is at work) before proceeding with this problem as I am
unable to replicate it.

To help me, which versions of the following have you got installed?

libgnomeui, libbonoboui, pcre, popt, gtk and vte (including, if you have them,
the devel rpms)
Comment 7 Bryan Christ 2006-03-24 10:22:58 EST
okay... here they are with probably more than you requested.  there aren't any
corresponding devel packages installed for these.

libgnomeui-2.14.0-1
libbonoboui-2.14.0-1
pcre-6.3-1.2.1
popt-1.10.2-15.2
gtk2-engines-2.7.4-3
gtk2-2.8.15-1
gtk+-1.2.10-50
vte-0.12.0-1.fc5.1
Comment 8 Paul F. Johnson 2006-03-24 10:53:03 EST
They're the same versions as I have on the x86 box and my x86_64 machine and I
can't reproduce the problem on either (I've tried all sorts of things to get the
errors to occur).

Straw-clutcher : have you got selinux set to permissive?
Comment 9 Michael Schwendt 2006-03-24 10:53:50 EST
Confirmed.

Paul, running ldconfig is irrelevant here, since /usr/lib/anjuta is
not in dynamic linker's standard search list anyway. libanjuta_clsGen.so
does not depend on any non-standard library either:

$ ldd /usr/lib/anjuta/libanjuta_clsGen.so
        linux-gate.so.1 =>  (0x003f0000)
        libc.so.6 => /lib/libc.so.6 (0x00972000)
        /lib/ld-linux.so.2 (0x00544000)

The missing symbols are undefined actually:

$ objdump -T /usr/lib/anjuta/libanjuta_clsGen.so|grep file_is_directory
00000000      D  *UND*  00000000              file_is_directory
Comment 10 Bryan Christ 2006-03-24 11:12:37 EST
Paul,

After I installed fc5, one of the first things I did was to disable selinux.
Comment 11 Paul F. Johnson 2006-03-24 11:17:41 EST
file_is_directory is defined in src/utilities.c which, in build directory has
been made and the object file

When I've done the ld on /usr/lib64/anjuta/libanjuta_clsGen.so, I get roughly
the same libs, but not the linux-gate.so.1. The file_is_directory is missing
though, so I'll need to look into the build for that. The Makefile inside of src
definately links in utilities.o. Hmmmm.

linux-gate.so.1 is a new one on me, but the following link does provide some
insight into it.

http://www.trilithium.com/johan/2005/08/linux-gate/

It doesn't look like it should be causing any problems.
Comment 12 Michael Schwendt 2006-03-24 13:07:52 EST
I'm going to rebuild it locally here and take a look. It smells like
the executable is not linked with --export-dynamic
Comment 13 Michael Schwendt 2006-03-24 13:25:18 EST
Created attachment 126658 [details]
patch against anjuta 1.2.4
Comment 14 Michael Schwendt 2006-03-24 13:26:07 EST
Created attachment 126659 [details]
trivial spec changes
Comment 15 Michael Schwendt 2006-03-24 13:30:47 EST
Unrelated, but display the Help About dialog gives:

** (anjuta:4558): WARNING **: Can not open AUTHORS file for reading

Inside the package source there's

  PACKAGE_DOC_DIR = /usr/share/doc/anjuta

but the %doc files are in /usr/share/doc/anjuta-1.2.4/ which
means another patch would be needed for that (or a symlink).
Comment 16 Paul F. Johnson 2006-03-24 13:43:57 EST
Thanks. I'll apply and test.
Comment 17 Paul F. Johnson 2006-03-27 04:28:48 EST
Has the update fixed the problem?
Comment 18 Kevin Kofler 2006-03-27 22:04:22 EST
The update was pushed only to devel, you need to build it for FC5 too. 
Comment 19 Kevin Kofler 2006-03-31 22:14:18 EST
Oh, and AFAICT you don't need to ask for a CVS sync as you did, you only need 
to do that when creating NEW branches (i.e. after the FIRST import). You only 
have to rerun cvs-import.sh with "-b FC-5" parameters to import your SRPM on 
the FC5 branch. Please read http://fedoraproject.org/wiki/Extras/UsingCvsFaq 
more thouroughly. (Readers, please correct me if I am mistaken.) 
Comment 20 Kevin Kofler 2006-03-31 22:22:57 EST
I asked for confirmation on the fedora-extras-list just to be sure. 
Comment 21 Kevin Kofler 2006-04-02 16:27:37 EDT
Ping... This bug not only causes error messages, it also causes all the 
features relying on the 3 plugins which fail to load to break (including 
trivial things like creating new files), so Anjuta is pretty much unusable in 
FC5/i386 right now, and the fix is already available, how long do we have to 
wait for the build? 
 
By the way, your FC4 build was the same old 1.2.3-1 build again. You need to 
cvs-import your new SRPM to all branches first and then request a rebuild. 
Comment 22 Paul F. Johnson 2006-04-02 18:37:38 EDT
This is odd. From my understanding, when you ask for a package to be moved to
one of the other branches, it's the current version which is moved not some old
version or other. It is certainly the case for the likes of fuse-emulator where
a version didn't already exist

The fix was definitely put in and tested for the rawhide version.

I'll seek clarification on the extras list and if it is the case that I need to
import and make build, then I'll do it.
Comment 23 Michael Schwendt 2006-04-02 18:58:51 EDT
You *never* ask for "a package to be moved".

You update your files in CVS in the individual branch directories
(/anjuta/FC-5, /anjuta/FC-4, /anjuta/FC-3, with /anjuta/devel being
the default directory for builds against Fedora Core Development.

Either manually with "cvs", or you cvs-import.sh entire src.rpms
into specific branches: cvs-import.sh -b FC-5 file.src.rpm
Then you "make tag" and "make build" as usual for every release
of the distribution you want binaries to be built and published.

No binary builds are ever requested to be moved or something like that.

Whatever you have misunderstood with regard to using the Wiki for
special removal/copy requests in the repository is independent from
ordinary package builds and has nothing to do with updating a
package in CVS. Similarly, requesting creation of _new_ branch
directories in CVS is completely unrelated to what you need to do
for updated builds of Anjuta.
Comment 24 Paul F. Johnson 2006-04-02 19:57:26 EDT
Apologies all around. I've now pushed anjuta-1.2.4-5 into both the FC-4 and FC-5
repos, so they should be available in tomorrows push.

Comment 25 Kevin Kofler 2006-04-02 23:37:38 EDT
It's now available and fixes the bug, so this can be closed again. 
Comment 26 Paul F. Johnson 2006-04-03 03:45:18 EDT
:-)

Again, my apologies for the mess up - I live, I learn.
Comment 27 Bryan Christ 2006-04-03 10:46:06 EDT
This bug appears fixed with anjuta-1.2.4-5.fc5 which I pulled down via yum
today. I think this bug can be closed.

Thanks!

Note You need to log in before you can comment on or make changes to this bug.