[Clfs-support] Having issues building GLIBC 32bit

[Koornstra, Reinoud]

Hi Gary,

I wonder even if you can do this:

CLFS_TARGET32=i686-altimatos-linux-gnu
CLFS_HOST=x86_64-altimatos-linux-gnu

I mostly put unknown there in case I build a build tool that HAS to work on any powerpc or any x86_64 platform.
Thinking about you might just do this, but I would do it when you're building the tools for the platform to boot itself.
This section:
III. Make the Cross-Compile Tools 

5. Constructing Cross-Compile Tools
Isn't the place to start doing this.
You could try temporary system, but eventually, chapter 10 would be the place to do this.

Trying to make a system from scratch is VERY meticulous so I'd advise to use the target and host only at chapter 10.
10. Installing Basic System Software
Thanks,

Reinoud.

-----Original Message-----
From: clfs-support-bounces at lists.cross-lfs.org [mailto:clfs-support-bounces at lists.cross-lfs.org] On Behalf Of Gary Greene
Sent: Saturday, May 10, 2014 4:12 PM
To: William Harrington
Cc: CLFS Support
Subject: Re: [Clfs-support] Having issues building GLIBC 32bit

On 10 May 2014, at 05:16am, William Harrington <kb0iic at berzerkula.org> wrote:
> On May 10, 2014, at 2:42 AM, Gary Greene wrote:
>> /home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(ns_print.os): In function `__GI_ns_sprintrrf':
>> ns_print.c:(.text+0x48f): undefined reference to `__stack_chk_guard'
>> ns_print.c:(.text+0x5b8): undefined reference to `__stack_chk_guard'
>> /home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(gethnamaddr.os): In function `getanswer':
>> gethnamaddr.c:(.text+0x766): undefined reference to `__stack_chk_guard'
>> gethnamaddr.c:(.text+0x7a5): undefined reference to `__stack_chk_guard'
>> /home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(gethnamaddr.os): In function `__GI_res_gethostbyname2':
>> gethnamaddr.c:(.text+0x109c): undefined reference to `__stack_chk_guard'
>> /home/builder/sources/glibc-build-32/resolv/libresolv_pic.a(gethnamad
>> dr.os):gethnamaddr.c:(.text+0x127e): more undefined references to 
>> `__stack_chk_guard' follow
> 
> echo "libc_cv_ssp=no" > config.cache
> 
> Did you do that prior to running configure as stated here:
> http://cross-lfs.org/view/git/x86_64/cross-tools/glibc.html
> 
> Gcc static is built before this step with  --disable-libssp 
> http://cross-lfs.org/view/git/x86_64/cross-tools/gcc-static.html
> I notice you are using x86_64-altimatos-linux-gnu-gcc  instead of x86_64-cross-linux-gnu-gcc at this step which means you changed your vendor in the target triplet.
> You should change your vendor when you build the final system if you want altimatos as your vendor in the target triplet. Even though changing the vendor can fool autotools into thinking a cross compiler is being used or built, use cross as in the book to minimize some issues, if the issue isn't from disabling ssp during gcc final static or during eglibc configure.
> 
> Sincerely,
> William Harrington

I did add the libc_cv_ssp=no in config.cache, as required, GCC static is configured as stated in the book.

As far as the tuple is concerned, yes, I did change it from the one in the CLFS book, as I'm using CLFS to allow me to build a clean build root for AltimatOS. My environment in the builder user (my equivalent of the clfs user) follows:

builder:/home/builder$ env
CLFS_TARGET32=i686-altimatos-linux-gnu
CLFS_HOST=x86_64-altimatos-linux-gnu
TERM=xterm
CLFS_TARGET=x86_64-altimatos-linux-gnu
LC_ALL=POSIX
BUILD64=-m64
CLFS=/AltimatOS
BUILD32=-m32
PATH=/cross-tools/bin:/cross-tools/sbin:/tools/bin:/tools/sbin:/System/bin:/System/sbin:/bin:/usr/bin
PWD=/home/builder
PS1=\u:\w\$
HOME=/Users/builder
_=/usr/bin/env