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.
did you use linux32 when chrooting to your 32bit env?
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 ?
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.
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)"
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...
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.
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.