Bug 161544 - mklibs loops infinitely after using chroot
Summary: mklibs loops infinitely after using chroot
Status: CLOSED DUPLICATE of bug 161543
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-24 05:18 UTC by Dao
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-24 09:19:05 UTC
Type: ---

Attachments (Terms of Use)

Description Dao 2005-06-24 05:18:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:

I am building an image base on linux kernel 2.6.7 or later but using linux 7.3 libraries. So I made a tarball with 7.3 libraries and untar on the Fedora Core 3, then chroot to it and build the image. The building process loops infinitely when mklibs reduces the library with the same number of unresolved symbols. 

Using the same tarball on Red Hat 9, go through the same steps to build the image, it works fine. 

I do not know why mklibs can find symbols on FC 3. Is there any difference for chroot or mklibs on Fedora Core 3 and Red Hat 9, or what different environment of the two systems caused the problem?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. tar development directory tree from Red Hat-7.3
2. untar it on Fedora Core 3 and chroot to it.
3. build image with mklibs to reduce the library.

Actual Results:  the process loops endlessly in mklibs with the same number of unsolved symbols.

Expected Results:  mklibs end up with 0 unsolved symbol.

Additional info:

Start Red Hat 9 with kernel 2.6.7, using the same steps, the image built successfully with 0 unresolved symbol.

Comment 1 Tim Waugh 2005-06-24 09:19:05 UTC

*** This bug has been marked as a duplicate of 161543 ***

Note You need to log in before you can comment on or make changes to this bug.