Summary: | sys-libs/glibc common.eblit calls multilib_env even not when cross compiling | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Benda Xu <heroxbd> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | prefix |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=588368 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 473728 | ||
Attachments: |
glibc-common_eblit.patch
common.eblit.patch common.eblit.patch |
Description
Benda Xu
2013-04-07 06:14:20 UTC
Created attachment 344686 [details, diff]
glibc-common_eblit.patch
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. (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. (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 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? Created attachment 344788 [details, diff]
common.eblit.patch
Created attachment 344790 [details, diff]
common.eblit.patch
(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. (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. BTW, moving "multilib_env ${CTARGET_OPT:-${CTARGET}}" inside "if is_crosscompile || tc-is-cross-compiler ; then .... ... ; fi" seems more natural, doesn't it? *** This bug has been marked as a duplicate of bug 588368 *** |