Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 64837 - procps installs libproc-3.2.3.so in /lib64 instead of /lib when compiling into a 32 bits chrooted environment on amd64
Summary: procps installs libproc-3.2.3.so in /lib64 instead of /lib when compiling int...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High minor (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-21 04:40 UTC by Jocelyn Mayer
Modified: 2005-01-10 14:05 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jocelyn Mayer 2004-09-21 04:40:48 UTC
I noticed that procps programs where all broken in my 32 bits chroot on my amd64 machine. The dynamic linker failed to find libproc.
This was not corrected when remerging the sys-apps/props package.
I finally found that the libproc was installed into /lib64 instead of /lib.
Moving the library solved the problem.
The current procps package configuration I use is:
# qpkg -I -i -v sys-apps/procps
sys-apps/procps-3.2.3-r1 *
        Standard informational utilities and process-handling tools [ http://procps.sourceforge.net/ ]
Compiled with USE Flags: -debug


Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Travis Tilley (RETIRED) gentoo-dev 2004-09-30 23:24:40 UTC
did you use linux32 when chrooting to your 32bit env?
Comment 2 Jocelyn Mayer 2004-10-01 02:16:14 UTC
I used linux32 to chroot.
procps is the only package that tries to use /lib64 when emerging.
uname -m in the chrooted environment gives me i686.
But I can notice that uname -m gives:
"AMD Athlon(tm) 64 Processor 3000+"
and /proc/cpuinfo is:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) 64 Processor 3000+
stepping        : 8

What other info could I give to help find where the problem is ?
Comment 3 Albert Cahalan 2005-01-06 11:06:12 UTC
If you're really in the chrooted environment, there should be
no problem unless you have a useless /lib64 directory there.

If you haven't called chroot() and can't, then you're
cross-compiling. This is fully supported. You'll need to
set a variable on the make command line. See the procps
README file.
Comment 4 SpanKY gentoo-dev 2005-01-09 12:54:27 UTC
was a bug in the makefile, it does a check to see if /lib64 exists

anyways, 3.2.4 has this now:
lib64="$(get_libdir)"
Comment 5 Albert Cahalan 2005-01-09 16:28:30 UTC
Practically the whole point of a Makefile variable is so that
you can set it on the command line. You don't need to patch
the Makefile. Why else would you think lib64 is a variable?

Red Hat does something like this:

make lib64=%{_lib} blah,blah,blah...
Comment 6 Albert Cahalan 2005-01-10 09:38:43 UTC
Oh, just a second...

You're not merely cross-compiling. You're planning to
actually run with this config, aren't you? That is
definitely not supported. You'll need to boot a 32-bit
kernel if you want to run a 32-bit ps.

Better yet, just use a 64-bit ps in your chroot.
You can statically link it if you'd rather not
install the 64-bit C library.
Comment 7 Jocelyn Mayer 2005-01-10 14:05:57 UTC
Is this a joke ?
I can perfectly run a 32 bits ps in a 32 chrooted environment using a 64 bits kernel when it's correctly installed.
I _do_ it, it works well and it has no reason not to work well.
And I just checked with sys-apps/procps-3.2.4, it now merges and run fine.
Thanks for the patch.