Summary: | BPREFIX variable needed to locate / binaries under cross-prefix setups | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | James Le Cuirot <chewi> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | prefix |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=317337 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
James Le Cuirot
2014-05-04 19:31:38 UTC
So, the problem here is that when calling an executable that is not in the path, calling ${EPREFIX}/usr/bin/myprogram breaks on cross-prefix builds; build-time dependencies and host-dependencies may not be present in the target prefix, and may not even run if they are. Instead, the myprogram executable in the host prefix should be called. One possible solution for this is having portage set an environment variable BPREFIX (build prefix) or HPREFIX (host prefix) containing the prefix of the host system. This would need an EAPI bump, and further complicates ebuilds needing it. Another possibility is to demand that all executables called must be in the path somehow. This has a certain kind of purity to it and certainly is more elegant, and simplifies ebuilds; however, having all host tools used in ebuilds be in the path may well introduce serious complications of its own. It is not clear to me which road would be preferable, or whether other possibilities exist. Thoughts? I'm reassigning this to prefix until it is clear how best to solve this. In terms of naming the variable, HPREFIX would tie in with HDEPEND, which is likely to be used at the same time. Not that HDEPEND is official... yet. ;) redlizard told me to list further uses of this so here's one. It's the same qmake-utils.eclass function from before but I missed this aspect of it. In order to override the host qmake's hardcoded paths when ROOT!=/, a qt.conf file like this has to be provided. [Paths] Binaries = ${EPREFIX}/usr/bin Libraries = ${EROOT}usr/$(get_libdir)/qt4 Headers = ${EROOT}usr/include/qt4 Data = ${EROOT}usr/share/qt4 Clearly the Binaries line is affected. I didn't think that I would need to specify this line at all as the hardcoded default should be correct but it seems that merely including a [Paths] section strips all existing path information and so it tries to find binaries like uic and moc in the same directory as qmake. That's okay though, right? Wrong! Qt looks for qt.conf in the strangest places and the least awkward one is in the same directory as qmake. For that reason, I create a symlink to qmake in ${T} as I obviously can't create /usr/bin/qt.conf. This is all very convoluted but Qt's madness isn't my fault. (In reply to James Le Cuirot from comment #2) > Not that HDEPEND is official... yet. ;) What does the "H" refer to here? (In reply to Michael Haubenwallner from comment #4) > (In reply to James Le Cuirot from comment #2) > > Not that HDEPEND is official... yet. ;) > > What does the "H" refer to here? It refers to /, the build host. See "man 5 ebuild" for details. (In reply to James Le Cuirot from comment #5) > > > Not that HDEPEND is official... yet. ;) > > > > What does the "H" refer to here? > > It refers to /, the build host. See "man 5 ebuild" for details. Ohw, indeed, thank you! Haven't followed the EAPI 5 development. But then we really should agree on the wording here to avoid potential confusion, be it for myself at least: On toolchain level, there is agreement on these for ages: BUILD where the current build is running on. HOST where the just created binaries will run after installing there. TARGET what architecture these HOST binaries will operate on. On portage level, currently we have these wordings: toolchain portage variables seen so far BUILD CBUILD "Host" HPREFIX BPREFIX HDEPEND(5) DEPEND(4) HOST CHOST "Target" ROOT EPREFIX DEPEND(5) RDEPEND PDEPEND TARGET CTARGET So for the portage variable namings, IMO we should kill BPREFIX in favour of HPREFIX now, even (and especially) in the cross-prefix patches. I must admit that I found the name HDEPEND a little confusing and maybe would have preferred BDEPEND but I don't care that much as long as it works. There's a long drawn out discussion about it in bug #317337 that we should probably avoid repeating in here. :) Having read through the entirety of the small novel that is the HDEPEND bug, I think the best solution regarding the BPREFIX/HPREFIX variable is to wait until HDEPEND will actually hit an EAPI, and then sneak BPREFIX/HPREFIX into that same EAPI proposal in a way that fits the HDEPEND solution. In the meantime, a workaround is possible. `EMERGE=$(which emerge); BPREFIX=${EMERGE%/usr/bin/emerge}` is a reliable way of finding out portage's primary prefix; we could add this to prefix.eclass if necessary. (In reply to Ruud Koolen from comment #8) > I think the best solution regarding the BPREFIX/HPREFIX variable is to wait > until HDEPEND will actually hit an EAPI, Agreed. (In reply to James Le Cuirot from comment #0) > In the meantime, a workaround is possible. `EMERGE=$(which emerge); > BPREFIX=${EMERGE%/usr/bin/emerge}` is a reliable way of finding out > portage's primary prefix; we could add this to prefix.eclass if necessary. Actually, no: ${[BH]PREFIX} should not be visible to the ebuilds in any way, nor should an ebuild rely on "$(which emerge)" at all: There is no guarantee to have anything being installed in the same Prefix as portage itself, but PATH shall contain usr/bin:bin for each Prefix in use. Instead, 'qmake' should be found via PATH somehow, using either providing 'usr/bin/qmake-qt4' and 'usr/bin/qmake-qt5' or "$(usr/bin/qt4-config --qmake)" and "$(usr/bin/qt5-config --qmake)" or "$(usr/bin/qt4-config --prefix)/bin/qmake" or "usr/bin/qmake" identifying itself whether to call 'qmake-qt4' or 'qmake-qt5' or "pkg-config Qt4" or something else. (In reply to Michael Haubenwallner from comment #9) > There is no guarantee to have anything being installed in the same Prefix as > portage itself, but PATH shall contain usr/bin:bin for each Prefix in use. That's why I said that this would probably be used in conjunction with HDEPEND. That provides the guarantee. (In reply to James Le Cuirot from comment #10) > (In reply to Michael Haubenwallner from comment #9) > > There is no guarantee to have anything being installed in the same Prefix as > > portage itself, but PATH shall contain usr/bin:bin for each Prefix in use. > > That's why I said that this would probably be used in conjunction with > HDEPEND. That provides the guarantee. There isn't necessarily /the one/ HPREFIX: There might be multiple, chained HPREFIXes, showing up in PATH each. (In reply to Michael Haubenwallner from comment #11) > There isn't necessarily /the one/ HPREFIX: > There might be multiple, chained HPREFIXes, showing up in PATH each. This path leads to the gates of madness? :| (In reply to James Le Cuirot from comment #12) > (In reply to Michael Haubenwallner from comment #11) > > There isn't necessarily /the one/ HPREFIX: > > There might be multiple, chained HPREFIXes, showing up in PATH each. > > This path leads to the gates of madness? :| Note that the "prefix-chaining" thingy (potentially with multiple prefixes in one chain) has moved forward and renamed to "prefix-stack" (with one single parent and child prefix) utilizing EAPI 7 along bug#658572, although "prefix-stack" is not really about cross compiling. Don't know why this is still open as it become BROOT in EAPI 7. |