[gentoo-amd64] Re: revdep-rebuild keep on detecting a broken link referred to libqt-mt.so.3

[Duncan]

Chris Brennan <xaero@××××××××××.net> posted
47C83FBF.3080905@××××××××××.net, excerpted below, on  Fri, 29 Feb 2008
12:24:15 -0500:

[Duncan wrote...]
>> Hmm... so what about /usr/qt/3/lib/libqt-mt.so ?  Here, it's a symlink
>> pointing to libqt-mt.so.3, a symlink pointing to libqt-mt.so.3.3, again
>> a symlink, pointing at libqt-mt.so.3.3.8, which is the actual
>> shared-object library file.
>
> the point was the error msg from the emerge output about wrong format.

The problem is, "wrong format" can mean symlink pointed at nothing, in some
contexts.  If the target file doesn't exist...

It can also mean it's for some reason it's pointed at a text file, or a
file of the wrong bitness, or a file-system corrupt file, or..., which
is what the next part is about.

>> If you have a valid set of symlinks, pick any one of them and see what
>> readelf -h says about it.  If the class entry (right under magic) is
>> anything other than ELF64, then you have a corrupted library and
>> probably need to remerge qt (be sure you remerge qt3 not 4, if you have
>> it merged as well).  If it's ELF64 and appears to be readable, then you
>> have other deeper problems.
>
> I have re-emerged qt-3 numerous times, here is the output of readelf
>
> xaero@Leviathan ~ $ readelf -h /usr/qt/3/lib/libqt-mt.so.3.3.8 ELF
> Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>   Class:                               ELF32

That's the problem right there.  It's trying to link a 32-bit library
into (presumably, since this is the amd64 list/group) a 64-bit
ELF binary.  That's just not going to work, period, and remerging
the 64-bit qt isn't going to correct the problem either (unless it
overwrites the file, which it obviously doesn't if you've tried it
already).

That's progress.  Now, we need to find out if any packages you have
merged, probably emul-linux-x86-* packages since that's where the
32-bit stuff comes from unless you are running a full 32-bit chroot,
and I've no indication of that.

equery belongs libqt-mt.so.3.3.8

I didn't use the path, since lib and lib64 are normally symlinked
one way or the other on amd64, and if you searched by path, you'd
need to search for both paths.

Here, I get one (just one) entry, but I'm running no-multilib since
I don't do binary-only and that's about the only reason one might
have for 32-bit.

[ Searching for file(s) libqt-mt.so.3.3.8 in *... ]
x11-libs/qt-3.3.8-r4 (/usr/qt/3/lib64/libqt-mt.so.3.3.8)

So it's the 64-bit qt package that owns it, here.  What about
there?  Do two packages own it and do both point at the same
file, possibly thru different directory/symlink paths?  None?

If none it's an orphaned file and you /should/ be able to remove
it safely, but you may want to move it somewhere out of the
library search path but keep it around for awhile just in case.

If only the 64-bit package points to it, same thing, but
remerge the 64-bit qt afterward, and I frankly don't know why
remerging it with that file in place didn't fix the problem.

If one and it's 32-bit, then you have a problem with the
lib-linking search path.  First, check for updates to the 32-bit
emul-linux-* package and try that if there are any.  Else there
are ways to fix it but you'll need to get someone with more
knowledge in the field to help, as I never had the problem on
multilib myself and now am 64-bit only so haven't bothered with
the details.

If two, and both paths point to the same thing, it's something
portage's config-protect FEATURE should have caught if you
have it enabled.  Again, check for updates on the 32-bit
package and try them first, then seek further help, but in
this case it's a bug that should either be in Gentoo's bugzilla
already or that you can file if not.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@l.g.o mailing list