How to bootstrap

[Daniel Schepler]

Hi, I've been trying to bootstrap an x32 chroot by adapting the
instructions from Linux From Scratch. Right now I'm stuck trying to
build gcc-4.7. How do I configure it so that it uses -mx32 as the
default, and more importantly builds an x32 stub version of libgcc.a?
I tried passing "--with-abi=mx32" as I saw in another message, but it
returns a message saying something like "this target does not support
--with-abi".

Here's how I'm currently trying to configure it:

../gcc-4.7.0/configure --target=$LFS_TGT --prefix=/tools --with-
sysroot=$LFS --with-newlib --without-headers --with-local-prefix=/
tools --with-native-system-header-dir=/tools/include --disable-nls --
disable-shared --disable-multilib --disable-decimal-float --disable-
threads --disable-libmudflap --disable-libssp --disable-libgomp --
disable-libquadmath --enable-languages=c --with-mpfr-include=$(pwd)/../
gcc-4.7.0/mpfr/src --with-mpfr-lib=$(pwd)/mpfr/src/.libs

with LFS_TGT=x86_64-lfs-linux-gnux32 and LFS=/opt/lfs.

But this generates an -m64 libgcc.a.

More generally, I can't seem to find any documentation on how to
configure gcc, glibc, etc. for x32 mode. Is there something obvious
that I'm missing?
--
Daniel Schepler

[H.J.]

I have a wiki page

http://sourceware.org/glibc/wiki/x32

for bootstrapping x32 gcc/glibc.

H.J.

[H.J.]

On Jun 5, 10:56 am, Daniel Schepler <dschep...@gmail.com> wrote:

> Hi, I've been trying to bootstrap an x32 chroot by adapting the
> instructions from Linux From Scratch.  Right now I'm stuck trying to
> build gcc-4.7.  How do I configure it so that it uses -mx32 as the
> default, and more importantly builds an x32 stub version of libgcc.a?
> I tried passing "--with-abi=mx32" as I saw in another message, but it
> returns a message saying something like "this target does not support
> --with-abi".
>

You need gcc 4.8.0 or hjl/x32/gcc-4_7-branch branch for --with-abi.


H.J.

[Daniel Schepler]

On Jun 5, 11:12 am, "H.J." <hjl.to...@gmail.com> wrote:

> I have a wiki page
>
> http://sourceware.org/glibc/wiki/x32
>
> for bootstrapping x32 gcc/glibc.

OK, thanks. But looking at it, it looks like the gcc built there
needs -mx32 passed to it.

Is "--with-abi=mx32" support something that wasn't in the GCC 4.7.0
release? If so, where would I find a patch / SCM branch with that
support?
--
Daniel Schepler

[Daniel Schepler]

On Tuesday, June 5, 2012 11:15:32 AM UTC-7, H.J. wrote:

You need gcc 4.8.0 or hjl/x32/gcc-4_7-branch branch for  --with-abi.

All right, nvm my previous post.

A possibly silly question: where do I check out hjl/x32/gcc-4_7-branch from?
--
Daniel Schepler

[H.J. Lu]

hjl/x32/gcc-4_7-branch is available from

http://gcc.gnu.org/git/?p=gcc.git;a=summary


--
H.J.

[Daniel Schepler]

All right, now I've gotten to the point of building glibc (which I'm doing from "git clone git://sourceware.org/git/glibc.git -b hjl/x32/release/2.15 glibc-2.15").  I configured with:

../glibc-2.15/configure --prefix=/tools --host=$LFS_TGT --build=$(../glibc-2.15/scripts/config.guess) --disable-profile --enable-add-ons --enable-kernel=3.4 --with-headers=/tools/include libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes

The compilation seemed to work just fine -- except that it's passing "-Wl,-dynamic-linker=/libx32/ld-linux-x32.so.2" instead of /tools/libx32/ld-linux-x32.so.2 as I expected.  Any idea why that might be?  I do see a suspicious line in config.make: "slibdir=/libx32".
--
Daniel Schepler

[Mike Frysinger]

On Tue, Jun 5, 2012 at 5:51 PM, Daniel Schepler <dsch...@gmail.com> wrote:
> All right, now I've gotten to the point of building glibc (which I'm doing
> from "git clone git://sourceware.org/git/glibc.git -b hjl/x32/release/2.15
> glibc-2.15").  I configured with:
>
> ../glibc-2.15/configure --prefix=/tools --host=$LFS_TGT
> --build=$(../glibc-2.15/scripts/config.guess) --disable-profile
> --enable-add-ons --enable-kernel=3.4 --with-headers=/tools/include
> libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes
>
> The compilation seemed to work just fine -- except that it's passing
> "-Wl,-dynamic-linker=/libx32/ld-linux-x32.so.2" instead of
> /tools/libx32/ld-linux-x32.so.2 as I expected.  Any idea why that might be?

that's correct behavior. the full path to the ldso is part of the ABI.

if you want to execute a different ldso, you have to do so manually.
i think there's a bunch of examples on the libc-help/libc-alpha list.

there's also:
http://sourceware.org/glibc/wiki/Debugging/Loader_Debugging#Debugging_With_An_Alternate_Loader
-mike

[Daniel Schepler]

On Tuesday, June 5, 2012 3:04:50 PM UTC-7, Mike wrote:

On Tue, Jun 5, 2012 at 5:51 PM, Daniel Schepler wrote:
> The compilation seemed to work just fine -- except that it's passing
> "-Wl,-dynamic-linker=/libx32/ld-linux-x32.so.2" instead of
> /tools/libx32/ld-linux-x32.so.2 as I expected.  Any idea why that might be?

that's correct behavior.  the full path to the ldso is part of the ABI.

It's inconsistent with how the configure script behaves on x86_64 or i386. In those cases, if you configure glibc with a prefix other than "/usr", it uses a custom ldso path under that prefix.  (sysdeps/unix/sysv/linux/configure.in, lines 150-180 or so)  Maybe it would be more consistent just to add a new case "x86_64/x32" to that case statement instead of having it set in sysdeps/x86_64/preconfigure?

In the case of Linux From Scratch, this is intentional, to try to avoid using the system libraries as much as possible while bootstrapping.
--
Daniel Schepler

[H.J. Lu]

Please open a glibc bug. I will take a look.

Thanks.


--
H.J.

[Daniel Schepler]

On Tuesday, June 5, 2012 3:20:13 PM UTC-7, Daniel Schepler wrote:

Maybe it would be more consistent just to add a new case "x86_64/x32" to that case statement instead of having it set in sysdeps/x86_64/preconfigure?

Here's a simple patch implementing this, tested here with "--prefix=/tools" and "--prefix=/usr".
--
Daniel Schepler
 

[H.J. Lu]

Please open a glibc bug report and send the patch to libc-alpha
mailing list.


--
H.J.

[Daniel Schepler]

On Tuesday, June 5, 2012 4:47:19 PM UTC-7, H.J. wrote:

Please open a glibc bug report and send the patch to libc-alpha
mailing list.

I might have spoken too soon.  It looks like all dynamically linked binaries are segfaulting (including getconf, localedef, etc. built already in glibc sources).  On the other hand, statically linked binaries work fine, as does running "ld-linux-x32.so.2 --list /tools/bin/getconf" or libc-2.15.so directly.  But I'm not sure if it's something in my partial build environment (no shared libgcc, etc) which might have caused that, or if it's a bug triggered by compiling with a non-default ld.so path.

I'll still try to open the bug report sometime later tonight.
--
Daniel Schepler
 

[H.J. Lu]

Please try master branch first before opening a bug report.

Thanks.


--
H.J.

[Daniel Schepler]

On Tuesday, June 5, 2012 6:05:44 PM UTC-7, H.J. wrote:

On Tue, Jun 5, 2012 at 5:46 PM, Daniel Schepler <dsch...@gmail.com> wrote:
> I might have spoken too soon.  It looks like all dynamically linked binaries

> are segfaulting ...
>

Please try master branch first before opening a bug report.

Good news -- after another round of rebuilding binutils and gcc, glibc built fine with my patch and --prefix=/tools, and the segfaults are resolved.  Unfortunately, I haven't had time yet to try master branch.
--
Daniel Schepler

[H.J. Lu]

It is OK. But all changes have to be made on master branch
first.

Thanks.

--
H.J.

[Daniel Schepler]

On Tuesday, June 5, 2012 6:05:44 PM UTC-7, H.J. wrote:

Please try master branch first before opening a bug report.

It looks like configuring with a prefix other than /usr works as expected on master branch.
--
Daniel Schepler

[H.J. Lu]

In that case, you can use your patch on x32 2.15 backport. I have
no plan to update my x32 2.15 branch since 2.16 will be
release soon.


--
H.J.

[Daniel Schepler]

Fair enough.  I based my preliminary Debian packages on a git checkout of master in any case.  And I'd guess that by the time Linux From Scratch supports x32, they'd be using glibc 2.16 or later too.
--
Daniel Schepler