Opened 15 years ago

Closed 14 years ago

Last modified 12 years ago

#134 closed defect (fixed)

glibc compilation error `multiple __memcpy_chk definition`

Reported by: insecure Owned by: clfs-commits@…
Priority: major Milestone:
Component: BOOK Version:
Keywords: glibc Cc:

Description

I'm just fiddling around with CLFS. I used the following version:
"Cross-Compiled Linux From Scratch - Version SVN-20071221-x86"
HOST and TARGET environment variables are:
CLFS_HOST="x86_64-cross-linux-gnu"
CLFS_TARGET="i586-pc-linux-gnu"
The host system is a 64bit gentoo without multilib.

Everything went fine until the compilation of glibc in chapter 5. Then I got errors from make telling me about multiple __memcpy_chk definition and multiple __memset_chk definition.

I found the solution to this "behaviour" on http://bugs.gentoo.org/show_bug.cgi?id=199479 . The same bug. It seems like it is an i586-only problem. I applied the patch from here: http://sources.gentoo.org/viewcvs.py/gentoo/src/patchsets/glibc/2.7/0040_all_glibc-i586-chk.patch?rev=1.1 with

cd /mnt/lfs/sources/glibc-2.7
patch -Np0 -i ../0040_all_glibc-i586-chk.patch

Then compiled again and it worked. (I repeated the glibc part completely to be sure to have a clean source tree.)

Attachments (1)

0040_all_glibc-i586-chk.patch (1.2 KB) - added by insecure 15 years ago.
glibc 2.7 memcpy_chk memset_chk patch

Download all attachments as: .zip

Change History (4)

Changed 15 years ago by insecure

glibc 2.7 memcpy_chk memset_chk patch

comment:1 Changed 15 years ago by Joe Ciccone

Although it looks like you stumbled across a nice error that needs to be addressed. I can tell you already that this build will not work by the book if you follow the chroot method. I'm really getting sick of explaining this so I think it's time something goes in the book. Everything in /tools will get compiled for $CLFS_TARGET, but the final system is compiled for the output of config.guess, unless you want to specifically specify i586-pc-linux-gnu for everything. config.guess gets its cpu information from uname, which in turn gets it from the kernel, easist way to get around this, load a uname hack module into the kernel which changes the uts machine type to whatever you want. You can find an up to date version at.

http://cross-lfs.org/~jciccone/uname_hack-20071212.tar.bz2

comment:2 Changed 14 years ago by Joe Ciccone

Resolution: fixed
Status: newclosed

fixed in r3885

Note: See TracTickets for help on using tickets.