The interest of using glibc directly grows[1] besides the use of crosscompiling. 1. https://wiki.gentoo.org/wiki/Prefix/libc Reproducible: Always
Created attachment 351336 [details, diff] glibc.patch 1. add prefix support 2. side effect of bug 464916. Mike, if you do not want to put multilib-env inside is_crosscompile, then condition it against use prefix. (no multilib in Prefix and everything is lib) 3. side effect of bug 473484
Comment on attachment 351336 [details, diff] glibc.patch >-alt_prefix() { >+alt_arch_prefix() { > is_crosscompile && echo /usr/${CTARGET} > } > >+alt_prefix() { >+ is_crosscompile && echo "${EPREFIX}/usr/${CTARGET}" >+} do you really need to keep alt_arch_prefix sep ? seems like every place that gets called, you actually want alt_prefix. >- pushd "${D}"/$(get_libdir) >/dev/null >+ pushd "${ED}"/$(get_libdir) >/dev/null these ebuilds are EAPI=0, so you have to initialize ED and EROOT somewhere >- glibc_sanity_check >+ use prefix || glibc_sanity_check put that check in the sanity check func itself >+ --with-headers="$(alt_eprefix)"$(alt_build_headers) >+ --prefix="$(alt_eprefix)"/usr >+ --libdir="$(alt_eprefix)"/usr/$(get_libdir) >+ --mandir="$(alt_eprefix)"/usr/share/man >+ --infodir="$(alt_eprefix)"/usr/share/info >+ --libexecdir="$(alt_eprefix)"/usr/$(get_libdir)/misc/glibc >+ --sysconfdir="$(alt_eprefix)"/etc >+ --localstatedir="$(alt_eprefix)"/var put the quotes around the whole RHS of the = >+ export libc_cv_slibdir="$(alt_eprefix)"/$(get_libdir) same here >+ --with-headers=$(alt_eprefix)$(alt_build_headers) >+ --prefix="$(alt_eprefix)"/usr and here > get_kheader_version() { > printf '#include <linux/version.h>\nLINUX_VERSION_CODE\n' | \ >- $(tc-getCPP ${CTARGET}) -I "$(alt_build_headers)" | \ >+ $(tc-getCPP ${CTARGET}) -I "${EPREFIX}/$(alt_build_headers)" | \ seems to me that you should include $EPREFIX in the output of alt_build_headers. everywhere you call that func, you manually add the prefix (and not consistently at that). >+ epatch "${FILESDIR}"/2.17/locale-gen_prefix.patch we're not patching the file. keep unrelated (to this bug) changes out. > inherit eutils versionator toolchain-funcs flag-o-matic gnuconfig multilib unpacker multiprocessing >+inherit prefix keep it all on one line
Created attachment 351386 [details, diff] glibc.patch updated with nice explanation of offsets. The assignment of EROOT / ED in pkg_setup phase is forbidden somehow, saying ED/EROOT is readonly variable.
Created attachment 351388 [details, diff] glibc.patch
Created attachment 351402 [details, diff] glibc.patch 1. ED EROOT are protected variables, assigning them gets failed. 2. without explicit definition of ED/EROOT in Gentoo vanilla, it emerges without problem. Not sure about the reason here for EAPI 0. Tested environments are: Portage 2.2.01.22013-prefix (!../../../home/benda/art/hack/tauon/profiles/prefix/linux/amd64/with-libc, gcc-4.7.2, unavailable, 2.6.35-14.1.el5.elrepo x86_64) ================================================================= System uname: Linux-2.6.35-14.1.el5.elrepo-x86_64-Intel-R-_Xeon-R-_CPU_E5606_@_2.13GHz-with-redhat-5.8-Final KiB Mem: 33007992 total, 1011332 free KiB Swap: 0 total, 0 free Timestamp of tree: Wed, 19 Jun 2013 05:41:34 +0000 ld GNU ld (GNU Binutils) 2.23 distcc 3.1 x86_64-pc-linux-gnu [enabled] app-shells/bash: 4.2_p39-r1 dev-lang/python: 2.7.5 dev-util/pkgconfig: 0.28 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.4 sys-devel/binutils: 2.23 sys-devel/gcc: 4.7.2-r1 sys-devel/gcc-config: 1.8-r00.1::heroxbd sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.9 (virtual/os-headers) sys-libs/glibc: 2.17::heroxbd Repositories: gentoo_prefix heroxbd ACCEPT_KEYWORDS="~amd64-linux" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=corei7" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe -march=corei7" DISTDIR="/opt/gentoo/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distcc distlocks ebuild-locks fixlafiles force-prefix merge-sync news parallel-fetch preserve-libs protect-owned sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1" MAKEOPTS="-j40" and Portage 2.1.12.4 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 3.9-1-amd64 x86_64) ================================================================= System uname: Linux-3.9-1-amd64-x86_64-Intel-R-_Xeon-R-_CPU_E5606_@_2.13GHz-with-gentoo-2.2 KiB Mem: 16471224 total, 6688796 free KiB Swap: 1354748 total, 1354748 free Timestamp of tree: Sun, 16 Jun 2013 02:00:01 +0000 ld GNU ld (GNU Binutils) 2.22 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.2_p45 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo heroxbd ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j16" PKGDIR="/usr/portage/packages"
(In reply to Benda Xu from comment #5) > 2. without explicit definition of ED/EROOT in Gentoo vanilla, it emerges > without problem. Portage behavior does not match PMS for EAPI {0..2} when FEATURES=force-prefix is enabled. It's documented in the make.conf man page.
(In reply to Zac Medico from comment #6) yeah, relying on that behavior isn't going to fly. i thought in the past we did things like: : ${ED:=${D}} : ${EROOT:=${ROOT}} does that not work ? or did we just do: [[ -z ${ED} ]] && ED=${D} [[ -z ${EROOT ]] && EROOT=${ROOT}
Created attachment 351436 [details, diff] glibc.patch Using vapier's suggestion : ${ED:=${D}} : ${EROOT:=${ROOT}}
Comment on attachment 351436 [details, diff] glibc.patch i think you should commit just the $ED & $EROOT changes. those all look fine and it'll make it easier to focus on the rest.
Created attachment 352204 [details, diff] glibc-1.patch Applied ED/EROOT patch to cvs. This the remaining patch.
Hey Mike, this is a friendly ping on this bug. Prefix support for glibc is also needed for crossdev on Prefix.
Greetings! Setting EROOT in the ebuild is breaks installing binary packages with different values for ROOT than they were built with. Now with ${EROOT:=${ROOT}} the value of EROOT is preserved in the package's environment and re-used by pkg_preinst() resulting in this strange situation: emerge --root=/tmp/root1 --buildpkg sys-libs/glibc rm -rf /tmp/root1 emerge --root=/tmp/root2 --usepkg sys-libs/glibc find /tmp/root1 /tmp/root1 /tmp/root1/etc /tmp/root1/etc/ld.so.conf.d etc/ld.so.conf.d is being created in the wrong root! This specific bug then causes other issues later on because tools like gcc-config will gracefully skip writing etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf and similar if etc/ld.so.conf.d doesn't already exist and as far as I can tell (so far) the pkg_preinst step in glibc is the only thing in Gentoo that will actually create that directory.
(In reply to Michael Marineau from comment #12) > Greetings! > > Setting EROOT in the ebuild is breaks installing binary packages with > different values for ROOT than they were built with. Now with > ${EROOT:=${ROOT}} the value of EROOT is preserved in the package's > environment and re-used by pkg_preinst() resulting in this strange situation: > > emerge --root=/tmp/root1 --buildpkg sys-libs/glibc > rm -rf /tmp/root1 > emerge --root=/tmp/root2 --usepkg sys-libs/glibc > find /tmp/root1 > /tmp/root1 > /tmp/root1/etc > /tmp/root1/etc/ld.so.conf.d > > etc/ld.so.conf.d is being created in the wrong root! This specific bug then > causes other issues later on because tools like gcc-config will gracefully > skip writing etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf and similar if > etc/ld.so.conf.d doesn't already exist and as far as I can tell (so far) the > pkg_preinst step in glibc is the only thing in Gentoo that will actually > create that directory. Thanks, Michael. It feels like a bug in portage to me. ROOT is not preserved in environment, neither should EROOT. I'll let bug 490014 track this issue instead.
(In reply to Benda Xu from comment #13) > > Thanks, Michael. It feels like a bug in portage to me. ROOT is not preserved > in environment, neither should EROOT. I'll let bug 490014 track this issue > instead. Yeah, I was debating where the bug really was but decided to give portage a pass since EROOT technically isn't special in EAPI=0 but perhaps it should be even if it isn't strictly defined to be so. :)
*** Bug 511816 has been marked as a duplicate of this bug. ***
*** Bug 495996 has been marked as a duplicate of this bug. ***
*** Bug 513434 has been marked as a duplicate of this bug. ***
Commit message: Split src_prepare out of src_unpack http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_prepare.eblit?rev=1.1 http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_unpack.eblit?r1=1.26&r2=1.27
Commit message: Split src_configure out of src_compile http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_compile.eblit?r1=1.44&r2=1.45 http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_configure.eblit?rev=1.1
Commit message: Upgrade EAPI to 4 http://sources.gentoo.org/sys-libs/glibc/glibc-2.20.ebuild?r1=1.1&r2=1.2
Commit message: Use SYSROOT when looking for source rather than ROOT http://sources.gentoo.org/sys-libs/glibc/files/eblits/common.eblit?r1=1.40&r2=1.41
Comment on attachment 352204 [details, diff] glibc-1.patch this will need refreshing, but seems like it'd be pretty straight forward to port to the latest code. i think alt_build_headers should handle $EPREFIX logic itself since it is tasked with finding the full path. the fallback logic that probes the location will return a fully qualified path, so inserting $EPREFIX in front of that is actually wrong. in the headers compile/configure paths, i don't think you need $TPREFIX (or $EPREFIX). it's only used when bootstrapping the toolchain in the cross compile scenario which means $TPREFIX is always going to be empty.
(In reply to SpanKY from comment #21) > Commit message: Use SYSROOT when looking for source rather than ROOT > http://sources.gentoo.org/sys-libs/glibc/files/eblits/common.eblit?r1=1. > 40&r2=1.41 I don't understand how one can depend on SYSROOT in ebuilds. To me SYSROOT is just an env. variable currently set by cross-emerge but I as far as I can tell SYSROOT is in no way an official variable like ROOT etc. is.
(In reply to SpanKY from comment #22) > Comment on attachment 352204 [details, diff] [details, diff] > glibc-1.patch > > this will need refreshing, but seems like it'd be pretty straight forward to > port to the latest code. > > i think alt_build_headers should handle $EPREFIX logic itself since it is > tasked with finding the full path. the fallback logic that probes the > location will return a fully qualified path, so inserting $EPREFIX in front > of that is actually wrong. > > in the headers compile/configure paths, i don't think you need $TPREFIX (or > $EPREFIX). it's only used when bootstrapping the toolchain in the cross > compile scenario which means $TPREFIX is always going to be empty. Now that glibc is at EAPI=4, perhaps timezone-data can move to PDEPEND?
(In reply to Joakim Tjernlund from comment #23) SYSROOT is the way to get at source code. ROOT is never used in src_* for source related things. (In reply to Joakim Tjernlund from comment #24) PDEPEND is in EAPI 0, and the topic of timezone data doesn't apply to this bug
(In reply to SpanKY from comment #25) > (In reply to Joakim Tjernlund from comment #23) > > SYSROOT is the way to get at source code. ROOT is never used in src_* for > source related things. But were is this stated? Never seen this descibed > > (In reply to Joakim Tjernlund from comment #24) > > PDEPEND is in EAPI 0, and the topic of timezone data doesn't apply to this > bug oh, I thought that it was in an later EAPI, my bad. Then I can play with this when I get some time :)
Hello all, I'm not 100% sure this happened due to recent changes in the eblits directory. But on my no-multilib amd64 box I wasn't able to compile glibc 2.19-r1. It failed with the same message you can find here: http://permalink.gmane.org/gmane.linux.gentoo.releng.autobuilds/736 * Messages for package sys-libs/glibc-2.19-r1: * Defaulting /etc/host.conf:multi to on * ERROR: sys-libs/glibc-2.19-r1::gentoo failed (preinst phase): * simple run test (/usr/bin/cal) failed * * Call stack: * ebuild.sh, line 93: Called pkg_preinst * environment, line 2910: Called eblit-run 'pkg_preinst' * environment, line 1029: Called eblit-glibc-pkg_preinst * pkg_preinst.eblit, line 54: Called glibc_sanity_check * pkg_preinst.eblit, line 33: Called die * The specific snippet of code: * ./ld-*.so --library-path . ${x} > /dev/null \ * || die "simple run test (${x}) failed" * * If you need support, post the output of `emerge --info '=sys-libs/glibc-2.19-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.19-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/glibc-2.19-r1/image/lib64' * S: '/var/tmp/portage/sys-libs/glibc-2.19-r1/work/glibc-2.19' Basically it went into /var/tmp/portage/sys-libs/glibc-2.19-r1/image/lib64 and tried to run ./ld-*.so. But there was just nothing in that dir except a broken symlink (ld-linux-x86-64.so.2). I did an emerge-webrsync --revert=20140908 (so a snapshot a few days older than recent changes) and was able to install glibc without issues. Sorry I don't have anything more definitive, but I thought I should bring it up. Kind regards, Sebastian
(In reply to Sebastian from comment #27) that was reported & fixed in a diff bug
Created attachment 390684 [details, diff] Prefix patch for glibc eblits Dear Mike, Thank you very much for your time! It is so exciting to see eblits supports the newest EAPI. I have refreshed the patch. (In reply to SpanKY from comment #22) > Comment on attachment 352204 [details, diff] [details, diff] > glibc-1.patch > > this will need refreshing, but seems like it'd be pretty straight forward to > port to the latest code. Yup. > i think alt_build_headers should handle $EPREFIX logic itself since it is > tasked with finding the full path. the fallback logic that probes the > location will return a fully qualified path, so inserting $EPREFIX in front > of that is actually wrong. Yes, you are right. I refactorized the code as you said. > in the headers compile/configure paths, i don't think you need $TPREFIX (or > $EPREFIX). it's only used when bootstrapping the toolchain in the cross > compile scenario which means $TPREFIX is always going to be empty. $TPREFIX is needed. It is used not only in "bootstrapping the toolchain in the cross compile scenario" but also in native compiling of Prefix (where TPREFIX=EPREFIX) and in cross-triplet-prefix (cross compiling and TPREFIX!=""). For example, --mandir="${TPREFIX}"/usr/share/man. The man pages of glibc in a Prefix system must go to "${TPREFIX}"/usr/share/man. During my consideration of your point here, I discovered a more elegant way to handle the complexity of the prefixes, as shown in the updated patch. Thanks again. Looking forward to hearing from you. Cheers, Benda
Created attachment 435510 [details, diff] glibc-eblit.patch Hi, Mike. I have cleaned up the patch and rebased it to the newest eblits. Please have a look.
Created attachment 435512 [details, diff] glibc-eblit.patch
all but the configure/econf changes are fine, so feel free to land those seems like --libexecdir could be set to '$(libdir)/misc/glibc' instead otherwise, i think the econf change needs to be reviewed in fuller detail as to all the flags it might be adding here. we want to make sure --libdir is always passed, as is --prefix (glibc will abort if it isn't). the --host/--build flags should also get checked.
(In reply to SpanKY from comment #32) > all but the configure/econf changes are fine, so feel free to land those > > seems like --libexecdir could be set to '$(libdir)/misc/glibc' instead > > otherwise, i think the econf change needs to be reviewed in fuller detail as > to all the flags it might be adding here. we want to make sure --libdir is > always passed, as is --prefix (glibc will abort if it isn't). the > --host/--build flags should also get checked. Thanks Mike. I have pushed commit a0b8f3652b5a1aa4. No configure -> econf was used.
Created attachment 436150 [details, diff] glibc-eblit-pkg_preinst.patch The final Prefix patch is to support Prefix bootstrap. The bootstrap of Prefix installs helper binaries (ls, date, etc.) inside EPREFIX/tmp before glibc. They are linked against host libraries Prefix glibc does not know, and they might have symbol conflicts because of different versions of glibc. Besides, it is not a big deal if glibc breaks during bootstrap, before a usable system is in use. Therefore we need a switch to skip sanity check.
(In reply to Benda Xu from comment #34) > Created attachment 436150 [details, diff] [details, diff] > glibc-eblit-pkg_preinst.patch > > The final Prefix patch is to support Prefix bootstrap. > > The bootstrap of Prefix installs helper binaries (ls, date, etc.) inside > EPREFIX/tmp before glibc. They are linked against host libraries Prefix > glibc does not know, and they might have symbol conflicts because of > different versions of glibc. > > Besides, it is not a big deal if glibc breaks during bootstrap, before a > usable system is in use. > > Therefore we need a switch to skip sanity check. Hi, Mike. Does it look good to land? I think catalyst can also make use of it, if you prefer another variable name.
*** Bug 583216 has been marked as a duplicate of this bug. ***
Ping Mike.
No objection was raised in the past 7 months. Landed the patch in tree. Thanks. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=63c6df1a0ce38bb72792aef3ced98f3ccba8c684
