I'm building the 1.0.0-rc4 x86_64 multilib book.

When building procps 32-bit (section 10.18), I saw a bunch of warnings
from ld about mismatched 32-bit versus 64-bit sections.  Looking closer
at the commands that were being run, the "gcc -m32" that the book
specifies is being overridden by the procps Makefile for some targets --
it's inserting a -m64 later in the gcc command.  So some of the code is
compiled in 32-bit mode, and some is compiled in 64-bit mode.  I don't
remember exactly what gets compiled in what mode, but if that's
important, I can find out.

Looking at the section of the Makefile that inserts this extra -m64, I
see this text:

# 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.

And indeed, some of the supposedly-32-bit executables created by this
step (or by manually doing a "make clean ; make m64=-m32 lib64=lib") do
not run correctly -- uptime, for instance, segfaults immediately.  The
64-bit binaries created in 10.19 run correctly (once /proc is mounted),
though.  (Or at least uptime and top do.)

It also seems that the only reason procps has a separate 32-bit build is
for a 32-bit version of libproc.so.*  But on my host system (LFS around
6.1, plus a large chunk of BLFS, plus a couple extra packages), the only
executables that link against libproc.* are from procps itself, so I'm
not sure a 32-bit version is even needed if the procps binaries are
built 64-bit.

So, my question is basically: Can we drop procps-32 completely from the
multilib book, or is the 32-bit libproc required for something else?  If
it's required for something else, does it work?  The procps Makefile
makes it sound like it won't.

I'm continuing this build without the 32-bit libproc, and I'll see what
happens.  But it'll probably be a day or two before CLFS is done, and a
while longer before the packages I use from BLFS are done.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev

Reply via email to