Kumar Appaiah wrote:
> tags 558964 + confirmed
> thanks
>
> Dear Peter,
>
> Thank you for notifying us of this.
>
> On Mon, Nov 30, 2009 at 07:32:45PM +0100, Peter Fritzsche wrote:
> > I build all packages some time ago with binutils-gold and your package
> > build without an hard failure, but I noticed that you seems to provide a
> > library in a specific library package so other packages can link against
> > it without problems.... but your shared object has still some unresolved
> > symbols which the program which links agaomst it must resolve. This isnt
> > a good idea because when you introduce new dependencies the package
> > previously linked against the old version will break because it doesnt
> > know about the new dependency. Maybe you could link against all needed
> > libraries so programs must not link against libraries which it doesnt
> > need to use.
>
> I agree.
>
> > More informations can be found at
> >
> > http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbeca
> >usebinutils-gold.2BAC8-indirectlinking dpkg-shlibdeps already showed you
> > the related warnings:
>
> [snip]
>
> > You've propably linked it with gcc instead of g++.
>
> This was happening. However, even after switching to g++, I get
> several of those warnings. Is there a way I could find out which
> libraries actually provide those symbols, so that I could just add
> them to the list of libraries to which I link? Could you suggest of a
> way I could do this?
Install all dependencies and you will probably find it by grepping interesting
folders. These are for example /usr/lib, /lib and your build-folder. You can
then check with `readelf -s` if they really provide that symbol or just using
them.
You can use c++filt to read a demangled version of a symbol.
_ZNK12EST_Features3valEPKc
would be for example
"EST_String::chop_internal(int, int, EST_String::EST_chop_direction) const".
So I would guess that libestools.so.1.2.96 must be linked against libestbase.so.
I checked it using `grep -rli _ZNK12EST_Features3valEPKc .` in the current link
folder and then checking the found libraries using
`readelf -s ....|grep _ZNK12EST_Features3valEPK`
(!!!! readelf shortens output of symbol names to 25 chars!!!!!)
Output of libestools.so is
254: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND
_ZNK12EST_Features3valEPK
This means it doesnt provide the symbol, but uses it.
Output for libestbase.so is
4185: 00000000000f4510 115 FUNC GLOBAL DEFAULT 12
_ZNK12EST_Features3valEPK
7406: 00000000000f4590 76 FUNC GLOBAL DEFAULT 12
_ZNK12EST_Features3valEPK
So it probably provides this function and another one which has the same
suffix. You can also use `nm --demangle=gnu libestbase.so` in some cases
to get the complete symbol name.
One is _ZNK12EST_Features3valEPKc and the other one
_ZNK12EST_Features3valEPKcRK7EST_Val. This translates to
EST_Features::val(char const*) const
EST_Features::val(char const*, EST_Val const&) const
Best regards,
Peter
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
