Joe Ciccone wrote:
> The make command I used was make m64="${BUILD32}" and that worked.
> Weird stuff.
Yep, I get that also; "make m64=-m32" (or ${BUILD32} in the language of
the book) works just fine. I'm still not sure if the 32-bit libproc is
needed, but if it works, it doesn't really matter. I did install the
libproc that got generated by "make m64=-m32", though.
I ran the "-m32 -m64" uptime under gdb, to see if I could figure out
where it segfaulted. I can't; it looks like it's happening somewhere
down in the bowels of either glibc or the kernel. The backtrace
addresses are all above 0xf0000000, which seems to be kernel space.
There are also some file names scattered about, either libproc,
ld-linux.so.2 (dl-init.c), and libc. But most addresses are in the file
"??" (which I think means no debugging info).
I am still a bit concerned about the comments in the Makefile about the
32-bit binaries on a 64-bit kernel causing data corruption, though.
We don't install the 32-bit binaries (well, we do, we just overwrite
them with 64-bit binaries when installing the 64-bit procps), though.
So if the procps author meant "executables" when he said "binaries"
(instead of "libraries or executables"), then we should be fine. I'm
wondering if I should contact the procps devs to see what kind of
corruption happens, and under what circumstances.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
