Bug 186508

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!

[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]#

I take it that those libs are in /usr/lib/anjuta?

Out of interest, if you run /sbin/ldconfig does that sort the problem?

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]#

I take it that those libs are in /usr/lib/anjuta?

Out of interest, if you run /sbin/ldconfig does that sort the problem?

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)

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

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?

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

Paul,

After I installed fc5, one of the first things I did was to disable selinux.

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.

I'm going to rebuild it locally here and take a look. It smells like
the executable is not linked with --export-dynamic

Created attachment 126658 [details]
patch against anjuta 1.2.4

Created attachment 126659 [details]
trivial spec changes

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).

Thanks. I'll apply and test.

Has the update fixed the problem?

The update was pushed only to devel, you need to build it for FC5 too. 

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.) 

I asked for confirmation on the fedora-extras-list just to be sure. 

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. 

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.

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.

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.

It's now available and fixes the bug, so this can be closed again. 

:-)

Again, my apologies for the mess up - I live, I learn.

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!