Summary: | ABI=x86 emerge =procps-3.2.5-r1 fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Simon Stelling (RETIRED) <blubb> |
Component: | Current packages | Assignee: | AMD64 Project <amd64> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 124816 |
Description
Simon Stelling (RETIRED)
2006-03-03 04:47:19 UTC
seems like this is a candidate for KERNEL_ABI: from Makefile: # Be 64-bit if at all possible. In a cross-compiling situation, one may # do "make m64=-m32 lib64=lib" to produce 32-bit executables. DO NOT # attempt to use a 32-bit executable on a 64-bit kernel. Packagers MUST # produce separate executables for ppc and ppc64, s390 and s390x, # i386 and x86-64, mips and mips64, sparc and sparc64, and so on. # Failure to do so will cause data corruption. since i couldn't find any library dependencies on libproc (only binary deps) we just force ABI=$KERNEL_ABI now. everything else doesn't work anyway according to the makefile i dont really get the "solution" here Without even hacking the code or Makefile: You can statically link it. You can link against uClibc. (last I heard) You can link against dietlibc. (last I heard) What you can't do is have a 32-bit procps run correctly on a 64-bit kernel. It fails the test suite. There is no good reason to do this anyway; it just makes your system slow and buggy. This suggests another option: run a 32-bit kernel. (still slow, but less buggy than a mismatched system) If space is the issue, perhaps you'd prefer busybox. a 32bit kernel isn't slower than a 64bit one he didnt say that LATER |