Bug 614282 – sys-libs/glibc - when adding values to MULTILIB_ABIS - In file included from rpc_main.c:37: /usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such file or directory

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Jan Ziak (atomsymbol) 2017-03-30 09:53:14 UTC]

Hello

Current state: The machine has 2 ABIs enabled: amd64, x86.

Target state: The machine has 3 ABIs enabled: amd64, x32, x86.

Steps to reproduce the issue:

1. /etc/portage/make.conf: Add abi_x86_x32 to USE
2. /etc/portage/make.conf: Add MULTILIB_ABIS="amd64 x32 x86"
3. /etc/portage/profile/use.mask: Add "-abi_x86_x32"
4. $ emerge sys-libs/glibc

In file included from /usr/include/features.h:389:0,
                 from /usr/include/errno.h:28,
                 from rpc_main.c:37:
/usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such file or directory
 # include <gnu/stubs-x32.h>

$ qfile -e /usr/include/gnu/*
sys-libs/glibc-2.22-r4 (/usr/include/gnu/libc-version.h)
sys-libs/glibc-2.22-r4 (/usr/include/gnu/lib-names-32.h)
sys-libs/glibc-2.22-r4 (/usr/include/gnu/lib-names-64.h)
sys-libs/glibc-2.22-r4 (/usr/include/gnu/lib-names.h)
sys-libs/glibc-2.22-r4 (/usr/include/gnu/stubs-32.h)
sys-libs/glibc-2.22-r4 (/usr/include/gnu/stubs-64.h)
sys-libs/glibc-2.22-r4 (/usr/include/gnu/stubs.h)

[Comment 1 Jan Ziak (atomsymbol) 2017-03-30 09:55:39 UTC]

Created attachment 468626 [details]
sys-libs:glibc-2.22-r4:20170330-093041.log.gz

[Comment 2 Jeroen Roovers (RETIRED) 2017-03-30 10:01:41 UTC]

In file included from /usr/include/features.h:389:0,
                 from /usr/include/errno.h:28,
                 from rpc_main.c:37:
/usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such file or directory
 # include <gnu/stubs-x32.h>
                            ^
compilation terminated.
make[2]: *** [Makefile:165: /var/tmp/portage/sys-libs/glibc-2.22-r4/work/build-x32-x86_64-pc-linux-gnu-nptl/sunrpc/cross-rpc_main.o] Error 1

[Comment 3 Jeroen Roovers (RETIRED) 2017-03-30 10:02:27 UTC]

Your `emerge --info` output, please.

[Comment 4 Jan Ziak (atomsymbol) 2017-03-30 12:10:15 UTC]

Created attachment 468628 [details]
emerge-info.txt

[Comment 5 Steven Newbury 2017-03-30 22:21:21 UTC]

This is because the emerge has been attempted on a non-x32 profile based stage3/existing system where the toolchain doesn't have full support for x32.

Can we have amd64 always have support for x32?  It would make it much easier (read: possible) to transition an existing system, or even just selectively emerge certain packages for x32.

[Comment 6 Jan Ziak (atomsymbol) 2017-03-31 11:05:30 UTC]

In the meantime:

I was forced to temporarily add "-usersandbox" to FEATURES in /etc/portage/make.conf. Otherwise gcc crashes.

Example of the sandbox not working:

$ emerge -1 libogg
checking for x86_64-pc-linux-gnux32-gcc... x86_64-pc-linux-gnu-gcc -mx32
checking whether the C compiler works... no
configure: error: in `/var/tmp/portage/media-libs/libogg-1.3.2/work/libogg-1.3.2-abi_x86_x32.x32':
configure: error: C compiler cannot create executables
See `config.log' for more details

[Comment 7 Mike Gilbert 2017-06-18 23:55:32 UTC]

An easy *workaround* for this failure is to copy /usr/include/gnu/stubs-x32.h from an existing x32 install, or an x32 stage3 tarball.

You'll get a file collision on that file when you re-install glibc, so make sure collision-protect is off initially.

[Comment 8 Mike Gilbert 2017-06-18 23:57:33 UTC]

(In reply to Steven Newbury from comment #5)
> Can we have amd64 always have support for x32?  It would make it much easier
> (read: possible) to transition an existing system, or even just selectively
> emerge certain packages for x32.

We would still have the problem of how to bootstrap x32 support on thousands of existing amd64 installations.

[Comment 9 Andreas K. Hüttel 2017-09-11 09:49:40 UTC]

(In reply to Steven Newbury from comment #5)
>
> Can we have amd64 always have support for x32?  It would make it much easier
> (read: possible) to transition an existing system, or even just selectively
> emerge certain packages for x32.

Well, for me the main question is "is it worth the pain?"

[Comment 10 Reva Denis 2018-04-27 09:51:55 UTC]

>"is it worth the pain?"
I think we should fix this bug because the gentoo is about the choise and the freedom :).

[Comment 11 Sergei Trofimovich (RETIRED) 2018-04-27 19:28:17 UTC]

I think it's a good idea to have rudimentary support that use case in general.

Not that long ago we have accidentally killed 32-bit libraries for amd64 multilib glibc and it happened to be very easy to recover from it:
    https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b297eb4b3b9114b1663b5affd9e3a9f0c22fedd

I had an impression it was very simple to bootstrap x32 support in glibc as long as there is minimal crt files already available.

[Comment 12 Andreas K. Hüttel 2018-09-11 15:18:51 UTC]

(In reply to Sergei Trofimovich from comment #11)
> I think it's a good idea to have rudimentary support that use case in
> general.
> 
[...]
> 
> I had an impression it was very simple to bootstrap x32 support in glibc as
> long as there is minimal crt files already available.

Given that we now have the minimal crt binary files delivered with glibc sources, is this fixed?

[Comment 13 Andreas K. Hüttel 2018-10-26 19:54:00 UTC]

This seems to be fixed now (tested with 2.28-r1).