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

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

[manuel]

Hi All,
I've ran revdep-rebuild a couple of times this week  and each  time i 
run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each 
time It emerges
app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem! 
but the broken link is still there!?? I can't fix it! any ideas?

thanks in advance for your help

Manuel

-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

manuel <kaos@manuelmarano.com> posted 47C6789C.2060508@manuelmarano.com,
excerpted below, on  Thu, 28 Feb 2008 10:02:20 +0100:

> Hi All,
> I've ran revdep-rebuild a couple of times this week  and each  time i
> run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each
> time It emerges
> app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem!
> but the broken link is still there!?? I can't fix it! any ideas?

Realize that the emul-linux-x86 stuff is binary.  That is, it's prebuilt; 
the ebuild simply installs it, because compiling it as 32-bit on a 64-bit 
multilib system is possible but rather a hassle to setup correctly, so 
the 32-bit binary emul-linux stuff is provided as a convenience for those 
who don't wish to go thru that hassle.

As a binary, you can remerge it all day every day and it's not going to 
change the binaries inside.  Thus, you can't correct linking therein.  A 
new binary package would be required for that.

However, such binaries aren't critical for a 64-bit system anyway.  All 
they do is support 32-bit binary-only games and the like, if you choose 
to install and run them.  Thus, the broken linkage isn't a big deal 
unless it's stopping you from running that game or whatever, and even 
then, it's not interfering with the normal functioning of the computer in 
general.

To fix it, you'd either need to wait for an updated build, merge whatever 
additional emul-linux package it's linking against (but the remerge 
should have cured the problem if it were that, as it would have pulled in 
the other package), or do the whole 32-bit chroot thing and use it rather 
than the emul-linux stuff.

If all you wish to do is get revdep-rebuild to shutup, that is, set it to 
ignore that package since remerging it isn't going to help, that's 
possible too.  See the revdep-rebuild manpage for the details, but 
basically, you put an entry in either make.conf itself, or in a file in 
/etc/revdep-rebuild, telling revdep-rebuild what to ignore.  (This 
feature has been in the ~arch revdep-rebuild version for some time.  I 
assume it's in arch-stable versions by now.  If not and you're running 
stable, consider running ~arch gentoolkit, using the appropriate 
package.keywords entry.)

-- 
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@lists.gentoo.org mailing list

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

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

2008/2/28, manuel <kaos@manuelmarano.com>:
>
> Hi All,
> I've ran revdep-rebuild a couple of times this week  and each  time i
> run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each
> time It emerges
> app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem!
> but the broken link is still there!?? I can't fix it! any ideas?
>
> thanks in advance for your help
>
> Manuel


log in a terminal as user, then  do a rm /root/.revdep* and then try again
revdep-rebuild. after you do a revdep-rebuild be always sure that no .revdep
files are present anymore in the /root/ directory. if there are some present
then revdep will continue to cicle through them.
another option would be to run revdep-rebuild -i (which stands for --ignore)
which would ignore the .revdep files in the /root/ directory. i personally
prefer the first option since i know that there aren't any cached revdeped
files. if it continues to cycle on the same rebuild after one rebuild then
it might be the case of a bug like the one of the gcj use flag in gcc-4.1.
try searching on the forum if that might be the case.



-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1530 bytes --]

[gentoo-amd64] a different revdep-rebuild problem and solution

[Steve Herber]

I had a slightly different revdep-rebuild problem and this discussion was
the impetus to uncover the cause.  The problem I had was that every time
I ran revdep-rebuild it wanted to rebuild a package that I had removed
and the package name was really weird.  At the end of the run it emitted
this command which I have reformatted for easy reading:

emerge --oneshot
 	=media-tv/-MERGING-mythtv-0.20_p11626
 	=media-tv/-MERGING-mythtv-0.20_p12172
 	=app-cdr/cdrkit-1.1.6
 	=media-libs/xine-lib-1.1.10.1

I didn't have any problem with the last two items, but I could not find
the weird -MERGING-mythtv packages.  I did remember having an emerge
problem with MythTV when I first started to try it.  After looking around
and not finding a likely suspect, I ran strace -f -o /tmp/revdep.out
revdep-rebuild.  After it hung I searched through all the open system
calls and finally found it checking out files in

 	/var/db/pkg/media-tv.

In the directory media-tv were subdirectories with the -MERGING name.
I removed all the directories in media-tv and reran revdep-rebuild and
all was well.

Thanks for the help!


Steve Herber	herber@thing.com		work: 206-221-7262
Security Engineer, UW Medicine, IT Services	home: 425-454-2399

On Thu, 28 Feb 2008, Beso wrote:

> 2008/2/28, manuel <kaos@manuelmarano.com>:
>>
>> Hi All,
>> I've ran revdep-rebuild a couple of times this week  and each  time i
>> run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each
>> time It emerges
>> app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem!
>> but the broken link is still there!?? I can't fix it! any ideas?
>>
>> thanks in advance for your help
>>
>> Manuel
>
>
> log in a terminal as user, then  do a rm /root/.revdep* and then try again
> revdep-rebuild. after you do a revdep-rebuild be always sure that no .revdep
> files are present anymore in the /root/ directory. if there are some present
> then revdep will continue to cicle through them.
> another option would be to run revdep-rebuild -i (which stands for --ignore)
> which would ignore the .revdep files in the /root/ directory. i personally
> prefer the first option since i know that there aren't any cached revdeped
> files. if it continues to cycle on the same rebuild after one rebuild then
> it might be the case of a bug like the one of the gcj use flag in gcc-4.1.
> try searching on the forum if that might be the case.
>
>
>
> -- 
> dott. ing. beso
>
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: a different revdep-rebuild problem and solution

[Duncan]

Steve Herber <herber@thing.com> posted
Pine.LNX.4.64.0802282342530.26122@thing.com, excerpted below, on  Fri, 29
Feb 2008 00:05:46 -0800:

> I had a slightly different revdep-rebuild problem[.]

> I could not find the weird -MERGING-mythtv packages.  I did remember
> having an emerge problem with MythTV when I first started to try it.

> [I finally found it in] /var/db/pkg/media-tv.
> 
> In the directory media-tv were subdirectories with the -MERGING name. I
> removed all the directories in media-tv and reran revdep-rebuild and all
> was well.

As you likely figured out, /var/db/pkg/ is portage's merged package 
database.  

As a bit of background, portage tries to work as safely with the system 
as possible, leaving as little time for a crash to affect system 
stability as possible.  Thus, it does all its compiling and a "fake 
install" to a temp location (PORTAGE_TMPDIR in make.conf, /var/tmp/ by 
default, with it adding the portage subdir to wherever the setting 
points, so normally /var/tmp/portage/), before doing the final qmerge 
step that merges everything from the fake location to the live filesystem.

Of course, as portage does that final qmerge it also has to add the 
package information to the system database in /var/db/pkg/.  Again, in 
ordered to minimize damage risk as much as possible, and to make it easy 
to correct the damage if something /does/ go wrong, portage initially 
creates and works in a tempdir in its package database, naming it 
MERGING- and the package name and version.  It then does the copy from 
the fake-install into the live filesystem as fast as possible, before 
finally renaming the temporary package database dir, removing the 
MERGING- prefix.

Thus, any MERGING-* entries in the database indicate partially merged 
packages.  Portage or the entire system crashed during the critical 
qmerge phase, and the merge wasn't able to complete.  It's wise to pay 
particular attention to such entries, as not only do they take up space 
in the database, but they indicate partially merged packages, some files 
of which are likely stuck in limbo on the live filesystem, orphaned in 
the incomplete qmerge step, not working and what's worse, very possibly 
triggering other system issues.  These other issues could range from the 
revdep-rebuild issues you noted, to conflicting configurations (tho 
that's not likely due to portage's config-protect features), to build 
complications for other packages due to them picking up the wrong 
versions of files, to security issues if someone can manage to run stale 
binaries or link in stale libraries with known vulnerabilities, because 
neither the package manager nor the sysadmin really realizes those 
potentially vulnerable files are still there!

Thus, it's important to properly clean up such partially merged packages 
when you find them.  Fortunately, if you go back and try merging the same 
package over again, portage will cleanup after itself.  Since that's what 
probably happens in the majority of cases, those MERGING entries are 
normally relatively temporary and cause no real problems.  However, if 
the sysadmin decides to try a different version or simply gives up on 
whatever he was trying to merge, THEN there's the potential complications 
mentioned above, and a good Gentoo sysadmin will take the necessary steps 
to clean things up manually.

Properly cleaning up is *NOT*, however, as simple as just deleting the 
MERGING-* entries in the package database.  Rather, if the package can't 
be merged even if it'll be immediately unmerged (this is often simplest 
when possible, as the cleanup is then automatic), one must manually check 
to see if any of the files listed in the MERGING-* dir actually exist on 
the main filesystem.  If they do, one should then run a query (equery 
belongs, or similar using your tool of choice) against the portage 
database to ensure no other merged packages (as might be the case if a 
different version was successfully merged) own the file in question, and 
if not delete it (or if one is extra careful, move it elsewhere for 
awhile to see if anything complains, just in case... as I said, sometimes 
other packages will have detected and built against the wrong version if 
it is still around due to a failed merge, they'll need rebuilt, but it 
can be useful to be able to move the file back if necessary until you can 
get the rebuild done).

So, you removed the MERGING-* temporary database entry, but did you 
ensure any files it listed weren't still around causing trouble on your 
live filesystem?  That's supposed to be done first, so you know exactly 
which files to check.  However, if you missed doing that, you can usually 
do the check anyway, tho at the cost of more hassle and risk of missing 
something.  In this case, again assuming the stale version is no longer 
in portage or otherwise can't be merged and unmerged, thus automating the 
process, the idea would be to check another version of the package, 
seeing what files it has, and that you don't have other orphaned versions 
of the same files still around.  Again, be sure to equery belongs 
anything that you find, before just removing it, just to be sure.

FWIW... the above is from experience...  I had unstable hardware at one 
point, and unfortunately ended up with a bit of experience cleaning up 
such messes.  I also ended up at one point with a portage database that 
didn't match what I had actually installed, due to an emergency rescue of 
a failing disk -- the backups I had of one part of the system didn't 
match the backups of a different part, didn't match the parts of the 
system I was able to successfully recover. =8^(  Now THAT was a MESS to 
clean up!  (Since then, I've made it a point to keep all the areas 
portage merges files to on the same partition and same backup as the 
package database.  Thus, if I lose my working system, when I recover, the 
entire installed system and package database will be in sync, all from 
the same date when I did the backup, so if I get lazy and let the backup 
get old and stale, at least it'll all be the SAME staleness!)

Hope that helps! =8^)

-- 
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@lists.gentoo.org mailing list

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

[manuel]

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]

Duncan ha scritto:
> manuel <kaos@manuelmarano.com> posted 47C6789C.2060508@manuelmarano.com,
> excerpted below, on  Thu, 28 Feb 2008 10:02:20 +0100:
>
>   
>> Hi All,
>> I've ran revdep-rebuild a couple of times this week  and each  time i
>> run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each
>> time It emerges
>> app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem!
>> but the broken link is still there!?? I can't fix it! any ideas?
>>     
>
> Realize that the emul-linux-x86 stuff is binary.  That is, it's prebuilt; 
> the ebuild simply installs it, because compiling it as 32-bit on a 64-bit 
> multilib system is possible but rather a hassle to setup correctly, so 
> the 32-bit binary emul-linux stuff is provided as a convenience for those 
> who don't wish to go thru that hassle.
>
> As a binary, you can remerge it all day every day and it's not going to 
> change the binaries inside.  Thus, you can't correct linking therein.  A 
> new binary package would be required for that.
>
> However, such binaries aren't critical for a 64-bit system anyway.  All 
> they do is support 32-bit binary-only games and the like, if you choose 
> to install and run them.  Thus, the broken linkage isn't a big deal 
> unless it's stopping you from running that game or whatever, and even 
> then, it's not interfering with the normal functioning of the computer in 
> general.
>
> To fix it, you'd either need to wait for an updated build, merge whatever 
> additional emul-linux package it's linking against (but the remerge 
> should have cured the problem if it were that, as it would have pulled in 
> the other package), or do the whole 32-bit chroot thing and use it rather 
> than the emul-linux stuff.
>
> If all you wish to do is get revdep-rebuild to shutup, that is, set it to 
> ignore that package since remerging it isn't going to help, that's 
> possible too.  See the revdep-rebuild manpage for the details, but 
> basically, you put an entry in either make.conf itself, or in a file in 
> /etc/revdep-rebuild, telling revdep-rebuild what to ignore.  (This 
> feature has been in the ~arch revdep-rebuild version for some time.  I 
> assume it's in arch-stable versions by now.  If not and you're running 
> stable, consider running ~arch gentoolkit, using the appropriate 
> package.keywords entry.)
>
>   
Great!!
thanks for the help

Manuel

[-- Attachment #2: Type: text/html, Size: 2917 bytes --]

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

[David Fellows]

On Thu, 28 Feb 2008 10:02:20 +0100 
manuel wrote -
> Hi All,
> I've ran revdep-rebuild a couple of times this week  and each  time i 
> run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each 
> time It emerges
> app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem! 
> but the broken link is still there!?? I can't fix it! any ideas?
> 
> thanks in advance for your help

Try 
  emerge -uvp app-emulation/emul-linux-x86-soundlibs

to see if there is a newer version available. If so, do
    emerge -uv app-emulation/emul-linux-x86-soundlibs  
to install it.

You might get cyclic dependencies reported. If they are among binary 
packages then you can  safely force emerging with the --nodeps option.

I think revdep-rebuild's logic does not apply to binary packages. It assumes
that emerging will result in relinking which does not happen for a binary 
package. You need to get a newer one with the new linking already done.

Taking the emerge command from revdep-rebuild -p and replacing the 
= with >= probably will achieve the same end.

Dave F
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Chris Brennan]

Beso wrote:
> 2008/2/28, manuel <kaos@manuelmarano.com>:
>> Hi All,
>> I've ran revdep-rebuild a couple of times this week  and each  time i
>> run it it finds  a  broken link  referred  to  libqt-mt.so.3 and each
>> time It emerges
>> app-emulation/emul-linux-x86-soundlibs-2007112 to correct the problem!
>> but the broken link is still there!?? I can't fix it! any ideas?
>>
>> thanks in advance for your help
>>
>> Manuel
> 
> 
> log in a terminal as user, then  do a rm /root/.revdep* and then try again
> revdep-rebuild. after you do a revdep-rebuild be always sure that no .revdep
> files are present anymore in the /root/ directory. if there are some present
> then revdep will continue to cicle through them.
> another option would be to run revdep-rebuild -i (which stands for --ignore)
> which would ignore the .revdep files in the /root/ directory. i personally
> prefer the first option since i know that there aren't any cached revdeped
> files. if it continues to cycle on the same rebuild after one rebuild then
> it might be the case of a bug like the one of the gcj use flag in gcc-4.1.
> try searching on the forum if that might be the case.
> 
> 
> 

I'm actually having the same issue as this w/ libqt-mt.so ... my problem
this, is gimp won't build because of it. below is the output.


/usr/qt/3/lib/libqt-mt.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[2]: *** [test-poppler-qt] Error 1
make[2]: Leaving directory
`/var/tmp/portage/app-text/poppler-bindings-0.6.1/work/poppler-0.6.1/qt'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/app-text/poppler-bindings-0.6.1/work/poppler-0.6.1'
make: *** [all] Error 2
 *
 * ERROR: app-text/poppler-bindings-0.6.1 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 2670:  Called die
 * The specific snippet of code:
 *       emake || die "compilation failed"
 *  The die message:
 *   compilation failed
 *
 * If you need support, post the topmost build error, and the call stack
if relevant.
 * A complete build log is located at
'/var/log/portage/app-text:poppler-bindings-0.6.1:20080229-164108.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/app-text/poppler-bindings-0.6.1/temp/environment'.
 *

 * Messages for package app-text/poppler-bindings-0.6.1:

 * disabling confcache, binary cannot be found
 *
 * ERROR: app-text/poppler-bindings-0.6.1 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 2670:  Called die
 * The specific snippet of code:
 *       emake || die "compilation failed"
 *  The die message:
 *   compilation failed
 *
 * If you need support, post the topmost build error, and the call stack
if relevant.
 * A complete build log is located at
'/var/log/portage/app-text:poppler-bindings-0.6.1:20080229-164108.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/app-text/poppler-bindings-0.6.1/temp/environment'.
 *
 * unmounting tmpfs ...
                                     [ ok ]
Leviathan htdocs #
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

Chris Brennan <xaero@xaerolimit.net> posted 47C836DD.50808@xaerolimit.net,
excerpted below, on  Fri, 29 Feb 2008 11:46:21 -0500:

> I'm actually having the same issue as this w/ libqt-mt.so ... my problem
> this, is gimp won't build because of it. below is the output.
> 
> 
> /usr/qt/3/lib/libqt-mt.so: could not read symbols: File in wrong format
> collect2: ld returned 1 exit status
> make[2]: *** [test-poppler-qt] Error 1 make[2]: Leaving directory
> `/var/tmp/portage/app-text/poppler-bindings-0.6.1/work/poppler-0.6.1/qt'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/var/tmp/portage/app-text/poppler-bindings-0.6.1/work/poppler-0.6.1'
> make: *** [all] Error 2

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.

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.


-- 
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@lists.gentoo.org mailing list

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

[Chris Brennan]

Duncan wrote:
> Chris Brennan <xaero@xaerolimit.net> posted 47C836DD.50808@xaerolimit.net,
> excerpted below, on  Fri, 29 Feb 2008 11:46:21 -0500:
> 
>> I'm actually having the same issue as this w/ libqt-mt.so ... my problem
>> this, is gimp won't build because of it. below is the output.
>>
>>
>> /usr/qt/3/lib/libqt-mt.so: could not read symbols: File in wrong format
>> collect2: ld returned 1 exit status
>> make[2]: *** [test-poppler-qt] Error 1 make[2]: Leaving directory
>> `/var/tmp/portage/app-text/poppler-bindings-0.6.1/work/poppler-0.6.1/qt'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory
>> `/var/tmp/portage/app-text/poppler-bindings-0.6.1/work/poppler-0.6.1'
>> make: *** [all] Error 2
> 
> 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.

> 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
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x1b2000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          7262824 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         25
  Section header string table index: 24
xaero@Leviathan ~ $



> 

-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

Chris Brennan <xaero@xaerolimit.net> posted
47C83FBF.3080905@xaerolimit.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@lists.gentoo.org mailing list

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

[Chris Brennan]

Duncan wrote:
> Chris Brennan <xaero@xaerolimit.net> posted
> 47C83FBF.3080905@xaerolimit.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.
> 

app-emulation/emul-linux-x86-qtlibs seems to have been the culprit, I
don't need it for anything that I can tell. It's been removed for now
and I have moved on to building the app I intended to build when all
this started (which was The Gimp). As of the writing of this, it is
building.
-- 
gentoo-amd64@lists.gentoo.org mailing list

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

[Duncan]

Chris Brennan <xaero@xaerolimit.net> posted
47C8D787.5060100@xaerolimit.net, excerpted below, on  Fri, 29 Feb 2008
23:11:51 -0500:

> app-emulation/emul-linux-x86-qtlibs seems to have been the culprit, I
> don't need it for anything that I can tell. It's been removed for now
> and I have moved on to building the app I intended to build when all
> this started (which was The Gimp). As of the writing of this, it is
> building.

Cool! =8^)  

Why it'd be putting a 32-bit lib in the standard lib dir is beyond me.  
It's certainly a bug.  It should be in a 32-bit compatibility dir (IDR 
what it was for sure because as I said I don't do multilib now), with 64-
bit libs in lib64, which is usually symlinked one way or the other to lib 
on a Gentoo system.  The only stuff that should go in lib itself (as 
opposed to lib64, even tho the two are linked, the package manager should 
still say lib64 for 64-bit) is bitness independent stuff.  For example, 
bash/perl/python scripts are allowed to install to straight lib.

So hopefully you don't end up needing that emul package for anything and 
don't have to worry about it any more.

-- 
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@lists.gentoo.org mailing list

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

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

2008/3/1, Duncan <1i5t5.duncan@cox.net>:
>
> Chris Brennan <xaero@xaerolimit.net> posted
>
> 47C8D787.5060100@xaerolimit.net, excerpted below, on  Fri, 29 Feb 2008
> 23:11:51 -0500:
>
>
> > app-emulation/emul-linux-x86-qtlibs seems to have been the culprit, I
> > don't need it for anything that I can tell. It's been removed for now
> > and I have moved on to building the app I intended to build when all
> > this started (which was The Gimp). As of the writing of this, it is
> > building.
>
>
> Cool! =8^)
>
> Why it'd be putting a 32-bit lib in the standard lib dir is beyond me.
> It's certainly a bug.  It should be in a 32-bit compatibility dir (IDR
> what it was for sure because as I said I don't do multilib now), with 64-
> bit libs in lib64, which is usually symlinked one way or the other to lib
> on a Gentoo system.  The only stuff that should go in lib itself (as
> opposed to lib64, even tho the two are linked, the package manager should
> still say lib64 for 64-bit) is bitness independent stuff.  For example,
> bash/perl/python scripts are allowed to install to straight lib.
>
> So hopefully you don't end up needing that emul package for anything and
> don't have to worry about it any more.


try to control if /usr/lib symlink goes on /usr/lib64 or on /usr/lib32. it
should never go to the 32bit lib on a 64bit machine. the same goes for the
/lib symlink.
also you might control what files has the emul-linux-x86-qtlibs via "qlist
emul-linux-x86-qtlibs" and see if it has merged something in the 64bit lib
(which shouldn't happen). also you might control the same thing with the the
64bit qt and see if there are some overlaps.


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 2199 bytes --]