Bug 475024 – crossdev: uses LIBDIR=lib for ABI=n32 mips (any ISA) for uclibc instead of the correct lib32

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Anthony Basile 2013-06-27 19:05:41 UTC]

When doing `USE="-* savedconfig" crossdev -t mips64-gentoo-linux-uclibc` with CONFIG_MIPS_N32_ABI=y in the uclibc config file, then building packages by cross emerging, we get a nicely populated ROOT=/usr/mips64-gentoo-linux-uclibc with one tiny hard to find problem.  LIBDIR=lib so ld.so is found at /lib/ld-uClibc.so.0 but readelf -x .interp on the elf objects says they're looking in /lib32/ld-uClibc.so.0.

Adding -A n32 to crossdev doesn't help.  You can, of course, manually fix this, but finding it is tough and could lead the unsuspecting user chasing non-bugs in uClibc/ldso.

Its a scary bug that makes little children cry.  It should be fixed.  This report is here to remind me to look more closely at crossdev in the future and fix it, if vapier doesn't beat me to it ;)


Reproducible: Always

[Comment 1 Anthony Basile 2013-06-27 19:33:47 UTC]

I should add that mips64-gentoo-linux-gnu is fine.

[Comment 2 SpanKY 2013-06-27 20:34:02 UTC]

looks correct to me:

# crossdev --init-target mips64-gentoo-linux-uclibc
# cat /etc/portage/env/cross-mips64-gentoo-linux-uclibc/uclibc.conf
LIBDIR_n32='lib32'
ABI='n32'
MULTILIB_ABIS='n32'
DEFAULT_ABI='n32'

but i'm not really sure what the problem is you're describing exactly.  why do you think LIBDIR=lib ?

[Comment 3 Anthony Basile 2013-06-27 21:27:27 UTC]

Just from direct inspection of the resulting chroot:

fuschia ~ # ls /usr/mips64-gentoo-linux-uclibc
bin  etc  lib  run  sbin  sys-include  tmp  usr  var

fuschia ~ # ls /usr/mips64-gentoo-linux-uclibc/lib/
cpp                    libc.so.0             libcrypt.so.0      libiconv.so.2.5.1  libncurses.so.5.9   libprocps.so.1.1.0      libresolv.so.0            libutil-0.9.33.2.so
ld-uClibc-0.9.33.2.so  libcharset.so.1       libdl-0.9.33.2.so  libkmod.so.2       libncursesw.so.5    libpthread-0.9.33.2.so  librt-0.9.33.2.so         libutil.so.0
ld-uClibc.so.0         libcharset.so.1.0.0   libdl.so.0         libkmod.so.2.2.3   libncursesw.so.5.9  libpthread.so.0         librt.so.0                libwrap.so.0
libattr.so.1           libcom_err.so.2       libeinfo.so        liblzma.so.5       libnsl-0.9.33.2.so  librc.so                libss.so.2                libwrap.so.0.7.6
libattr.so.1.1.0       libcom_err.so.2.1     libeinfo.so.1      liblzma.so.5.0.4   libnsl.so.0         librc.so.1              libss.so.2.0              libz.so.1
libbz2.so.1            libcrack.so.2         libhistory.so.6    libm-0.9.33.2.so   libpcre.so.1        libreadline.so.6        libthread_db-0.9.33.2.so  libz.so.1.2.8
libbz2.so.1.0          libcrack.so.2.9.0     libhistory.so.6.2  libm.so.0          libpcre.so.1.0.0    libreadline.so.6.2      libthread_db.so.1         modprobe.d
libbz2.so.1.0.6        libcrypt-0.9.33.2.so  libiconv.so.2      libncurses.so.5    libprocps.so.1      libresolv-0.9.33.2.so   libuClibc-0.9.33.2.so     rc


fuschia ~ # /usr/x86_64-pc-linux-gnu/mips64-gentoo-linux-uclibc/binutils-bin/2.23.1/readelf -x .interp /usr/mips64-gentoo-linux-uclibc/bin/bash 

Hex dump of section '.interp':
  0x10000174 2f6c6962 33322f6c 642d7543 6c696263 /lib32/ld-uClibc
  0x10000184 2e736f2e 3000                       .so.0.

[Comment 4 SpanKY 2013-06-27 21:37:16 UTC]

are your portage env .conf file looks like ... ?

[Comment 5 Anthony Basile 2013-06-27 21:55:37 UTC]

I think this is happening because I have USE="-* savedconfig" *and* MULTILIB_DIR="lib" in uclibc's config file.  I'm testing switching to MULTILIB_DIR=lib32.  I assume the .interp segment is emitted by gcc and I'm not sure how to change that without patching.

Here's what the env files looks like:

# cat uclibc.conf 
SYMLINK_LIB=no
COLLISION_IGNORE="${COLLISION_IGNORE} /usr/lib/debug/.build-id"


CFLAGS_amd64='-m64'
CFLAGS_n32='-mabi=n32'
CFLAGS_n64='-mabi=64'
CFLAGS_o32='-mabi=32'
CFLAGS_x32='-mx32'
CFLAGS_x86='-m32'
CHOST_amd64='x86_64-pc-linux-gnu'
CHOST_default=''
CHOST_n32='mips64-gentoo-linux-uclibc'
CHOST_n64='mips64-gentoo-linux-uclibc'
CHOST_o32='mips-gentoo-linux-uclibc'
CHOST_x32='x86_64-pc-linux-gnux32'
CHOST_x86='i686-pc-linux-gnu'
CTARGET_amd64='x86_64-pc-linux-gnu'
CTARGET_default='mips64-gentoo-linux-uclibc'
CTARGET_n32='mips64-gentoo-linux-uclibc'
CTARGET_n64='mips64-gentoo-linux-uclibc'
CTARGET_o32='mips-gentoo-linux-uclibc'
CTARGET_x32='x86_64-pc-linux-gnux32'
CTARGET_x86='i686-pc-linux-gnu'
LDFLAGS_amd64=''
LDFLAGS_n32=''
LIBDIR_amd64='lib64'
LIBDIR_default='lib'
LIBDIR_n32='lib32'
LIBDIR_n64='lib64'
LIBDIR_o32='lib'
LIBDIR_x32='libx32'
LIBDIR_x86='lib'
ABI='n32'
MULTILIB_ABIS='n32'
DEFAULT_ABI='n32'

[Comment 6 Anthony Basile 2013-06-27 22:10:36 UTC]

(In reply to Anthony Basile from comment #5)
> I think this is happening because I have USE="-* savedconfig" *and*
> MULTILIB_DIR="lib" in uclibc's config file.  I'm testing switching to
> MULTILIB_DIR=lib32.  

That fixed the issue.  Sorry for prematurely opening this before doing my homework, but I just couldnt see what was wrong in with crossdev so I figured something more subtle was happening.  Obviously the problem wasn't there.

[Comment 7 SpanKY 2013-06-27 23:01:06 UTC]

(In reply to Anthony Basile from comment #5)

yes, gcc's default spec files will set -dynamic-linker to a linker based on your target.  for mips/n32/uclibc, you get /lib32/ld-uClibc.so.0.

gcc/config/mips/gnu-user64.h:
      %{mabi=n32: -dynamic-linker " GNU_USER_DYNAMIC_LINKERN32 "} \

when it comes to USE=savedconfig, i'm sometimes torn.  on one hand, we have options that can bite and don't usually make sense, and we have dedicated USE flags.  on the other hand, we document USE=savedconfig as "this can bite you and will ignore your USE flags".