See also #74777. Don't know if it's a dup or not. (And I also have
this problem.)

I have this problem too.  In my case is because
libnautilus-tree-view.so is linked against old nautilus libraries
(installed in /usr/lib) at make install time.

I'm 95% sure it's a libtool bug, but I can't solve it for now.  When
relinking for installation libtool adds a -L/usr/lib at the beginning
of the command, thus spoiling it all.  I even don't know where this
option gets from, since I can't find it in my installed .la files.

Forgot to mention I'm compiling from cvs (updated 2002-03-23), and
installing in /opt/gnome2.  Conflicting library comes from 
nautilus-1.0.6-ximian.4 (RH7.2)

Ok, I found a workaround.  It seems libtool reverses the dependency
libs to handle interlib dependencies, so it also reverses -L flags. 
The patch puts those flags in the original order.  Though I'm not sure
it's the right thing to do, it works in this case.

Created attachment 7337 [details] [review]
Here's the patch

I've seen this problem myself. The reason seems to be that
libnautilus-private.la pulls in /usr/lib from the esound .la file or 
something like that.

I "solved" it by removing all my installed .la files :)

I don't want to ship a patched libtool though. We may break other
stuff if we change it.

I'm still having this problem.

So, um... if it works here (for jacob) why is it not working for
others? and don't we need some solution for this before we ship?

This works for me at this point... 

Still doesn't work for me.  The problem is libtool reverses the -L
flags when relinking, giving a -L/usr/lib before the -L$prefix (due to
some platform libraries).  So, if you have old nautilus installed in
/usr/lib and you're installing the new gnome2 nautilus to a different
prefix, the tree component gets linked to the old libraries
(libnautilus and libnautilus-private).  And since libnautilus.so.1 is
not binary compatible with libnautilus.so.2, the tree component fails
to activate.

One solution would be to change the nautilus library name to
libnautilus-2.so (and libnautilus-private-2.so) for example.

Everything will work fine if you don't have the old nautilus installed
or if you're installing in the same prefix (this is probably jacob's
case).

I agree with the diagnosis. I had the same problem, and after I
removed my old Nautilus libraries and recompiled the tree component
it started up fine.

I wonder if there is a libtool workaround for this.
Otherwise renaming the libraries sounds good.

*** Bug 76751 has been marked as a duplicate of this bug. ***

The patch I posted before works for me.  The version I patched is
1.4.2 and is installed in the same prefix as gnome2.  I can compile
the whole desktop without problems.  It might break some other build,
since it changes this feature (?) of libtool.

Anyway, it's probably not libtool's fault: shouldn't the linker choose
the latest available version of a library, even if both versions live
in separate directories?  Or is this the correct behavior?

I'm not really sure that this is a huge, gnome-wide problem at this
point so removing the 'high' designation. Parallel installs are
important but I'm not really certain parallel builds are a huge goal
and/or important from a user perspective. If it really affects that
many hackers someone will hack up a patch to nautilus :)

And clarifying the title to make it more clear when/how this is a problem.

*** Bug 74777 has been marked as a duplicate of this bug. ***

*** Bug 86398 has been marked as a duplicate of this bug. ***

I had the same problem myself, building from CVS. Just figured I'd
post my success story. This is what I did:

[root@baritone lib]# mkdir /naut-temp
[root@baritone lib]# mv libnautilus* /naut-temp
[root@baritone lib]# ldconfig
[root@baritone lib]# source ~/bin/gnome-head
[root@baritone lib]# modmake.sh nautilus

And then it just flat works after that. :)
Kind of a hacky workaround, but It Works For Me.

I have this problem using garnome on rh7.3. Confirm it appears to be a
libtool quirk. A quick and easy fix is to go to your gnome2 lib
directory and make a symbolic link
> ln -s libnautilus.so libnautilus.so.0

For any libtool guru interested in tracking it down...

All goes well, libraries linked correctly, up until install time. Make
install results in:

+ /bin/sh ../../libtool --debug  --mode=install /usr/bin/install -c
libnautilus-history-view.la /root/garnome/lib/libnautilus-history-view.la

Which causes a libtool 'relink' just before the install:

+ test -n 'cd
/usr2/garnome-0.12.2/gnome/nautilus/work/nautilus-2.0.0/components/history;
/bin/sh ../../libtool --mode=relink cc -O2 -pipe -g
-I/root/garnome/include -L/root/garnome/lib -o
libnautilus-history-view.la -rpath /root/garnome/lib -module
-avoid-version libmain.lo nautilus-history-view.lo
../../libnautilus/libnautilus.la
../../libnautilus-private/libnautilus-private.la -L/root/garnome/lib
-L/usr/X11R6/lib -leel-2 -lgnomeui-2 -lSM -lICE -lgailutil
-lbonoboui-2 -lgnomecanvas-2 -lgnome-2 -lart_lgpl_2 -lpangoft2-1.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0
-lpangox-1.0 -lpango-1.0 -lbonobo-2 -lgconf-2 -lgnomevfs-2
-lbonobo-activation -lORBit-2 -lxml2 -lz -lm -llinc -lgmodule-2.0 -ldl
-lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0'

Which produces the .soT file thus:

++ cc -shared libmain.lo nautilus-history-view.lo -Wl,--rpath
-Wl,/root/garnome/lib -L/usr/lib -L/usr/X11R6/lib -L/root/garnome/lib
-lnautilus -lnautilus-private -leel-2 -lgnomeui-2 -lSM -lICE
-lgailutil -lbonoboui-2 -lgnomecanvas-2 -lgnome-2 -lart_lgpl_2
-lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lbonobo-2 -lgconf-2
-lgnomevfs-2 -lbonobo-activation -lORBit-2 -lxml2 -lz -lm -llinc
-lgmodule-2.0 -ldl -lgobject-2.0 -lgthread-2.0 -lpthread -lglib-2.0
-Wl,-soname -Wl,libnautilus-history-view.so -o
.libs/libnautilus-history-view.so
++ mv -f libnautilus-history-view.so libnautilus-history-view.soT

Compare the previously created .so file with the .soT file (which is
what is ultimately installed to $LIB_DIR/libnautilus-history-view.so)

>garnome-0.12.2/gnome/nautilus/work/nautilus-2.0.0/components/history
>objdump -p .libs/nautilus-history-view.so | grep libnautilus.so
>  NEEDED      libnautilus.so.2
>
>objdump -p .libs/libnautilus-history-view.soT | grep libnautilus.so
>  NEEDED      libnautilus.so.0

I also have this problem using garnome on rh7.3.  The quick and easy
fix  (ln -s libnautilus.so libnautilus.so.0) did not work for me.

Sorry, after that you need to force a relink with the shared libraries
by doing a make install of nautilus, then you should be ok.

not sure if this will help or not... but i had the problem of all 
three sidebars crashing. after removing all user owned files in /tmp
order was restored.

No news on this bug for about one year. Is it still an issue with
nautilus 2.4 ? Could somebody look on this ?

Thanks

No feedback for more than a year, this bug seems to have fixed itself -- maybe
it's just the gradual disappearance of the gnome 1.x installs.