Re: Can't find the library . . .

[Mario Lang <mlang delysid org>]

Malcolm Tredinnick <malcolm commsecure com au> writes:

> On Mon, 2003-10-27 at 11:44, Mario Lang wrote:
>> Malcolm Tredinnick <malcolm commsecure com au> writes:
>> 
>> > On Sat, 2003-10-25 at 00:58, Nolan J. Darilek wrote:
>> >> I've been attempting to build the latest CVS gnopernicus, as I've
>> >> upgraded and downgraded numerous debian packages and my old compile no
>> >> longer works. I'm receiving the following error, though, and was
>> >> hoping someone could suggest something:
>> >> 
>> >> /bin/sh ../../libtool --mode=link gcc  -g -O2   -o test  test.o ../libsrconf/libsrconf.la ../../srutil/libsrutil.la -Wl,--export-dynamic -pthread -L/usr/local/stow/atk/lib -L/usr/local/stow/at-spi/lib -lgconf-2 -lcspi -lspi -lbonobo-2 -lgtk-x11-2.0 -lbonobo-activation -lORBit-2 -lgthread-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -lpopt 
>> >> mkdir .libs
>> >> libtool: link: cannot find the library `'
>> >> make[3]: *** [test] Error 1
>> >> make[3]: Leaving directory `/home/nolan/src/cvs/gnome/gnopernicus/srconf/test'
>> >> 
>> >> Any ideas what might be causing this? More importantly, which library
>> >> can't be found?
>> >
>> > This is usually a sign of one of libtools scripts becoming corrupted or
>> > horribly confused in some other way.
>> 
>> I am seeing the same problem since an apt-get upgrade of sid on Friday
>> last week.
>
> OK, so did libtool get upgraded as part of that upgrade?

Yes.

> If so, what version are you trying to run.

1.5-4 is current in Debian.

> If there are compatibility problems with libtool again then (a) I am
> disappointingly unsurprised, (b) it's extremely annoying, and (c) we
> really need to fix or everything is going to explode.
>
> Gnopernicus does nothing special at all w.r.t libtool, so if it is
> broken for current Sid users then half of GNOME is going to be broken.

I am a bit confused why the locally installed libtool version does matter at
all.  I am getting the impression that the libtool script used by
Gnopernicus is actually generated from ltmain.sh, also in Gnopernicus source
tree. Why is a change of the locally installed libtool version able to affect
the Gnopernicus build process at all? (Note that I am a complete libtool
idiot, so this question might be mightily silly).

> If libtool was upgraded for you, can you file a bug report for the
> gnome-common module and mark it urgent or something, please? Then I will
> see it and can keep some records to point others at. Gnopernicus uses
> gnome-common for this stuff, so that is where it needs to be fixed.
I am wondering if this problem did already show up in the Debian space,
and if someone perhaps has already found a solution... Checking
debian-gnome-gtk archives first...  Nope, doesn't look like it.
I can file that bug, but I'll have to figure out how to use
the bugzilla system first.

>> > The first thing to try and track down the problem (or to just plain make
>> > it disappear) is to start with a very clean gnopernicus source tree.
>> 
>> This problem also happens with a completely clear source base.  It
>> seems that the libtool script generated at configure time suddenly has
>> got problems coping with the -pthread argument.  The following patch
>> seems to fix the compile problem, however, I am currently totally at a
>> loss as to what the real source of the problem is.
>> 
>> --- ltmain.sh.orig	2003-10-27 01:38:45.000000000 +0100
>> +++ ltmain.sh	2003-10-27 01:31:54.000000000 +0100
>> @@ -1534,6 +1534,7 @@
>>  	  alldeplibs=yes
>>  	  continue
>>  	  ;;
>> +	-pthread) continue;;
>>  	esac # case $deplib
>>  	if test "$found" = yes || test -f "$lib"; then :
>>  	else
>
> Yuk. What a terrible place to have to apply a patch. :-(
I gree :-)


-- 
CYa,
  Mario | Debian Developer <URL:http://debian.org/>
        | Get my public key via finger mlang db debian org
        | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44