Bryan Kadzban wrote:
> 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.
>
> [snip]
The Makefile should not be inserting extra -m64s because CC="gcc -m32"
won't allow the test to compile a 64bit dummy prog pass. If it put a
-m64 in there I'd have to guess that -m32 wasn't passed on the command line.
check_gcc = $(shell if $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) dummy.c
$(ALL_LDFLAGS) $(1) -o /dev/null $(CURSES) > /dev/null 2>&1; then echo
"$(1)"; else echo "$(2)"; fi ;)
m64 := $(call check_gcc,-m64,$(call check_gcc,-mabi=64,))
>
> 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.
Linux sasquach 2.6.17 #4 SMP Fri Jul 14 15:36:03 EDT 2006 x86_64 x86_64
x86_64 GNU/Linux
Compiled with: make CC="gcc -m32"
uptime: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux
2.6.0, stripped
proc/libproc-3.2.7.so: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), stripped
LD_LIBRARY_PATH=$PWD/proc ldd uptime
linux-gate.so.1 => (0xffffe000)
libproc-3.2.7.so =>
/home/jciccone/sources/procps-3.2.7/proc/libproc-3.2.7.so (0xf7f96000)
libc.so.6 => /lib/libc.so.6 (0xf7e5f000)
/lib/ld-linux.so.2 (0xf7fb7000)
[EMAIL PROTECTED] ~/sources/procps-3.2.7 $ LD_LIBRARY_PATH=$PWD/proc
./uptime
23:18:00 up 2 days, 5:41, 9 users, load average: 0.10, 0.08, 0.02
ps, top, kill, and free also work for me.
Now I'm interested in why you're seeing this error and I'm not. Try
building it again and running the same commands I did above from the
source tree. It might help find the root of the problem.
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
