Bug 464916 – sys-libs/glibc common.eblit calls multilib_env even not when cross compiling

• Status: RESOLVED DUPLICATE of bug 588368
• Product: Gentoo Linux

[Description Benda Xu 2013-04-07 06:14:20 UTC]

sys-libs/glibc installs into lib64 even with USE=-multilib, while the expected libdir used is "lib".

The problem is, calling multilib_env unconditionally against multilib USE flag cases LIBDIR_amd64 in profile to be overwritten.

The following trivial patch fixes it.

Reproducible: Always

[Comment 1 Benda Xu 2013-04-07 06:21:19 UTC]

Created attachment 344686 [details, diff]
glibc-common_eblit.patch

[Comment 2 SpanKY 2013-04-07 06:57:24 UTC]

heh, no.  /lib64/ is the correct answer for amd64 regardless of USE=multilib.

ignoring that, the USE flag isn't what controls that setting.  LIBDIR_${ABI} is.

ignoring that, people trying to use /lib/ for amd64 are just doing it wrong.

[Comment 3 Benda Xu 2013-04-07 08:05:38 UTC]

(In reply to comment #2)
> heh, no.  /lib64/ is the correct answer for amd64 regardless of USE=multilib.

I doubt that. I can't see the reason of lib64 when we only use native64.

> ignoring that, the USE flag isn't what controls that setting.  LIBDIR_${ABI}
> is.

multilib_env overwrites LIBDIR_${ABI} in even make.conf

$ portageq envvar LIBDIR_amd64
lib

after calling multilib_env x86_64-pc-linux-gnu, LIBDIR_amd64 becomes lib64.

This behavior is not expected.

> ignoring that, people trying to use /lib/ for amd64 are just doing it wrong.

Any reference for this argument? side note: Gentoo Prefix is putting everything under lib and there is no lib64.

[Comment 4 SpanKY 2013-04-07 09:46:40 UTC]

(In reply to comment #3)

the ABI spec says to use /lib64/.  putting x86_64 binaries into /lib/ is dumb.

you can force the issue by doing something like:
  LIBDIR_crap=/lib/
  ABI=crap

[Comment 5 Benda Xu 2013-04-08 01:37:39 UTC]

Hi, Mike,

(In reply to comment #4)

> the ABI spec says to use /lib64/.  putting x86_64 binaries into /lib/ is
> dumb.

After digging around gentoo-dev ML and the spec, I see the reason for lib64 now.

> you can force the issue by doing something like:
>   LIBDIR_crap=/lib/
>   ABI=crap

Hmm, this is a way, though too dirty.


How about this? multilib_env is never designed to overwrite settings in profile, as the comments said:

# This is for the toolchain to setup profile variables when pulling in
# a crosscompiler (and thus they aren't set in the profile) 
multilib_env() {

Why don't we only call it in cross compiling?

[Comment 6 Benda Xu 2013-04-08 01:38:12 UTC]

Created attachment 344788 [details, diff]
common.eblit.patch

[Comment 7 Benda Xu 2013-04-08 01:39:20 UTC]

Created attachment 344790 [details, diff]
common.eblit.patch

[Comment 8 SpanKY 2013-04-08 03:36:22 UTC]

(In reply to comment #5)

what you want is dirty.  forcing you to use non-standard ABI names for a non-standard ABI setup seems reasonable to me.

i'm not really interested in changing the code as suggested.

[Comment 9 Benda Xu 2013-04-08 04:10:34 UTC]

(In reply to comment #8)
> what you want is dirty.  forcing you to use non-standard ABI names for a
> non-standard ABI setup seems reasonable to me.

This is another story.

Now the problem is multilib_env, a helper function written for cross compilation, is called in build of native glibc: It is abused.

[Comment 10 Benda Xu 2013-04-08 04:15:45 UTC]

BTW, moving "multilib_env ${CTARGET_OPT:-${CTARGET}}" inside "if is_crosscompile || tc-is-cross-compiler ; then .... ... ; fi" seems more natural, doesn't it?

[Comment 11 Benda Xu 2016-09-04 04:26:23 UTC]

*** This bug has been marked as a duplicate of bug 588368 ***