Joe Ciccone wrote: > Linux sasquach 2.6.17 #4 SMP Fri Jul 14 15:36:03 EDT 2006 x86_64 x86_64 > x86_64 GNU/Linux
I assume this is "uname -a", from inside chroot:
$ uname -a
Linux beta 2.6.17.11-64up #1 Tue Aug 29 20:08:34 EDT 2006 x86_64 x86_64
x86_64 GNU/Linux
> Compiled with: make CC="gcc -m32"
Yep, exactly that.
> 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
Assuming these are both from "file":
file uptime
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
file proc/libproc-3.2.6.so
proc/libproc-3.2.6.so: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), stripped
I do notice that you have procps 3.2.7 -- the 1.0.0rc4 book says to use
3.2.6, so that's what I had. Let me try 3.2.7 though...
Yep, 3.2.7 behaves exactly the same way (as far as proc/libproc-3.2.7.so
goes anyway). I'll continue with that in the rest of this email though.
> 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)
LD_LIBRARY_PATH=$PWD/proc ldd uptime
linux-gate.so.1 => (0xffffe000)
libproc-3.2.7.so =>
/usr/src/packages/procps/procps-3.2.7/proc/libproc-3.2.7.so (0xf7f53000)
libc.so.6 => /lib/libc.so.6 (0xf7e34000)
/lib/ld-linux.so.2 (0xf7f74000)
> [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
/usr/src/packages/procps/procps-3.2.7$ LD_LIBRARY_PATH=$PWD/proc
./uptime
Segmentation fault
I've also done some testing with gcc itself. I added a couple rules to
the procps Makefile, printvars (prints out lib64, CFLAGS, PKG_CFLAGS,
m64, ALL_CFLAGS, and the results of calling check_gcc with -m64 as the
first argument and an empty string as the second), and cccheck, which
runs a copy of the check_gcc command so I can see the real, full command
and all its output. Here're the results:
$ make CC="gcc -m32" printvars
lib64=lib64
CFLAGS=-O2 -s
PKG_CFLAGS=-fno-common -ffast-math -W -Wall -Wshadow -Wcast-align
-Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes
m64=-m64
ALL_CFLAGS=-fno-common -ffast-math -W -Wall -Wshadow -Wcast-align
-Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings
-Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -O2 -s -m64
-Wdeclaration-after-statement -Wpadded -Wstrict-aliasing -fweb
-frename-registers -fomit-frame-pointer -fno-inline-functions
check_gcc-m64=-m64
$ make CC="gcc -m32" cccheck
gcc -m32 -D_GNU_SOURCE -I proc -I/usr/include/ncurses -fno-common
-ffast-math -W -Wall -Wshadow -Wcast-align -Wredundant-decls
-Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return
-Wstrict-prototypes -Wmissing-prototypes -O2 -s -m64
Wdeclaration-after-statement -Wpadded -Wstrict-aliasing -fweb
-frename-registers -fomit-frame-pointer -fno-inline-functions dummy.c
-Wl,-warn-common -o /dev/null -lncurses
/usr/bin/ld: skipping incompatible
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../libncurses.so
when searching for -lncurses
/usr/bin/ld: skipping incompatible
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../libncurses.a when
searching for -lncurses
/usr/bin/ld: skipping incompatible
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../libgcc_s.so when
searching for -lgcc_s
/usr/bin/ld: skipping incompatible
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../libc.so when
searching for -lc
/usr/bin/ld: skipping incompatible
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../libc.a when
searching for -lc
/usr/bin/ld: skipping incompatible
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../libgcc_s.so when
searching for -lgcc_s
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../crt1.o' is
incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../crti.o' is
incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/tmp/ccidwlBw.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../crtn.o' is
incompatible with i386 output
I see that ld skips a bunch of libraries because they're incompatible
with -m32 (how it decided to do -m32 I'm not quite sure), but these are
only warnings. They don't prevent dummy.c from compiling.
Makes me wonder whether binutils is screwed up? I should probably state
at this point that I'm using the pkg-user hint, so that's a suspect as
well. But it does give me full compile and install logs from binutils,
so if there's something I should double-check there, let me know. The
testsuite log looks fine (no unexpected failures).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
