On Sat, Oct 28, 2006 at 10:22:47PM +0200, Kurt Roeckx wrote:
> > > The amd64 package (and all others that were built in old environments)
> > > can be fixed by binary-only uploads...
> >
> > No other architectures exhibit this bug, only amd64.
> [...]
> > Kurt, what gives? Why was this build daemon not operating like all others?
>
> >From the buildd log:
> dpkg-shlibdeps: warning: could not find any packages for libcourierauth.so.0
> dpkg-shlibdeps: warning: unable to find dependency information for shared
> library libcourierauth (soname 0, path libcourierauth.so.0, dependency field
> Depends )
>
> On amd64 you have the following rpath:
> RPATH /usr/lib:/usr/lib/courier-authlib
>
> While on i386 you have:
> RPATH /usr/lib/courier-authlib
Oddly enough...
> May I say that it's very annoying that all it shows is:
> Linking maildrop
>
> You even tell libtool to be --quiet.
>
> It would be alot more useful if all the commands that were used
> where in the buildd log.
I'll see if I can convince upstream to make it less quiet - it's their build
system, really.
> So, what actually happens is:
> g++ [...] -o maildrop deliver.o [...] varlist.o
> ./.libs/libmdcommon.a /usr/lib/libgdbm.so -L/usr/lib/courier-authlib
> /usr/lib/courier-authlib/libcourierauth.so -lcrypt -lpcre -Wl,--rpath
> -Wl,/usr/lib -Wl,--rpath -Wl,/usr/lib/courier-authlib -Wl,--rpath
> -Wl,/usr/lib -Wl,--rpath -Wl,/usr/lib/courier-authlib
>
> When I relink it without the 2 "-Wl,--rpath -Wl,/usr/lib", dpkg-shlibdeps
> seems to find it.
>
> If I upgrade libtool to the latest version, they're also gone, and
> dpkg-shlibdeps finds it's libraries. So I suggest you do that.
The same version of libtool doing two things on two different architectures
- sounds like another bug to me, although probably one already fixed by the
upgrade :)
Thanks.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
