glibc compilation error `multiple __memcpy_chk definition`

[insecure]

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

[insecure]

glibc 2.7 memcpy_chk memset_chk patch

[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

[Joe Ciccone]

fixed in r3885

[bascorp]

​доска бесплатных объявлений по украине