Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
mpfr-3.1.2-r1 fails to cross compile, maybe ebuild related
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
gemarcano
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2012
Posts: 100
Location: California

PostPosted: Mon Oct 14, 2013 6:55 am    Post subject: mpfr-3.1.2-r1 fails to cross compile, maybe ebuild related Reply with quote

I continue my rampage through packages that refuse to cross-compile correctly. I have been trying to cross compile packages on my ~amd64 desktop for my Raspberry Pi (armv6zk cpu, ~arm), and I've come across some problems in the emerge process for generating binary packages. The first problem I've dealt with is found here with regards to ACL. This problem with mpfr is different. When I first tried to emerge this packages using my cross-compiler, the configure step would fail giving an error about wrong executable file format. Just before that the config.log file was giving a warning about the wrong include folder being pointed to by the configure script. This led me to the ebuild, where the configure environment was being set up. For testing purposes, I did the following:
Code:
--- /usr/portage/dev-libs/mpfr/mpfr-3.1.2-r1.ebuild        2013-10-14 02:34:23.099158610 -0400
+++ /usr/local/portage/dev-libs/mpfr/mpfr-3.1.2-r1.ebuild     2013-09-13 14:32:04.000000000 -0400
@@ -46,8 +46,8 @@
 src_configure() {
        econf \
                --docdir="${EPREFIX}"/usr/share/doc/${PF} \
-               --with-gmp-lib="${EPREFIX}"/usr/$(get_libdir) \
-               --with-gmp-include="${EPREFIX}"/usr/include \
+               --with-gmp-lib="${EPREFIX}"/usr/armv6zk-hardfloat-linux-gnueabihf/usr/$(get_libdir) \
+               --with-gmp-include="${EPREFIX}"/usr/armv6zk-hardfloat-linux-gnueabihf/usr/include \
                $(use_enable static-libs static)
 }
Lo and behold, this makes it so that the package compiles successfully.

In the first bit of my experimentation I put in some echo debug statements in the ebuild to figure out what the EPREFIX variable was, and it is empty. The Gentoo documentation has this to say about EPREFIX:
Quote:
EPREFIX
Beginning with EAPI 3, contains the offset that this Portage was configured for during installation. The offset is sometimes necessary in an ebuild or eclass, and is available in such cases as ${EPREFIX}. EPREFIX does not contain a trailing slash, therefore an absent offset is represented by the empty string. Do not modify this variable.
I have a hard time making sense of this sentence. Does the documentation for EPREFIX mean that EPREFIX points to the offset of Portage as a whole (which seems to be the case)? I do not believe there is a "sub-Portage" that includes solely the cross-compile environment... right? Whatever the case is, on my system EPREFIX doesn't work when cross-compiling. I'm fairly tired right now, but tomorrow I'll come back and try to find a more general solution to this path issue and probably try to submit a patch for this. I briefly looked for a bug report on this issue, and found this, but I don't think this is related, so I may be filing a new bug report tomorrow.

As I mentioned, I'll try to find a solution to this issue tomorrow, but if anyone has any comments, I'll be more than glad to take them!

EDIT: I was really tired when I wrote this. The diff output above was inverted, fixed it this morning.


Last edited by gemarcano on Mon Oct 14, 2013 3:41 pm; edited 1 time in total
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Mon Oct 14, 2013 8:23 am    Post subject: Reply with quote

I had a similar issue with cross compiling from amd64 to i486-uclibc [3] . My best bet was a virtual maschine.

For your issue, i can also recommend qemu-user-static as desribed here.

[1] http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml
[2] http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml?part=1&chap=5
[3] https://forums.gentoo.org/viewtopic-t-969616-highlight-.html
Back to top
View user's profile Send private message
gemarcano
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2012
Posts: 100
Location: California

PostPosted: Mon Oct 14, 2013 2:24 pm    Post subject: Reply with quote

@schorsh_76
Thanks for your input. I have been considering running qemu just for efficiency's sake (as in, just getting things finally compiled instead of spending days debugging packages), but the performance hit of running qemu would be significant, even with my i7 CPU. I haven't benchmarked the performance of running an ARM system in qemu, but from what I've heard online it may not be worth doing so. In your case qemu for an i486 is not bad since amd64 is similar in architecture, but ARM is very different.

In terms of compilation I could just use distcc to offload a lot of the work from the Raspberry Pi (this is what I've done in the past), but I'm tired of sitting by the sidelines and not fixing broken programs/packages/ebuilds/etc. Thankfully mpfr seems to suffer only from a bad ebuild, so this should be easy to fix.
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Mon Oct 14, 2013 4:53 pm    Post subject: Reply with quote

I did a similar thing for the raspi. I did run qemu-user-static for arm in a chroot and did use distcc to compile native on the host. Way faster than compiling only in the qemu-user chroot.
Back to top
View user's profile Send private message
gemarcano
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2012
Posts: 100
Location: California

PostPosted: Mon Oct 14, 2013 5:18 pm    Post subject: Reply with quote

I need some input from anyone that knows about Gentoo Prefix.

In my investigation as to why the ebuild is failing at cross-compiling mpfr, I ran into the explanations of the variables EPREFIX and EROOT. After thinking about it, EPREFIX should be empty (and is in my runs) because I expect the binaries to be prepared for installation in the root directory because that's where the binary packages should install their files when unpacked. The problem I found with the ebuild is that it assumes EPREFIX is where the root of the system is located for finding include files and gmp libraries, which is not the case for a cross-compilation at all. A reasonable solution for this would be to replace these specific EPREFIXES with EROOT, but I found this in the Gentoo Prefix documentation:
Quote:
Using EPREFIX and EROOT

Given that ${EROOT} is ${ROOT}${EPREFIX}, using ${EROOT} or ${EPREFIX} is defined by the following rule. The rule is simple and automatable, whether or not it is "correct", for Gentoo Prefix this rule always holds:

If the main tree ebuild uses ${ROOT}, we respect ${ROOT} and usually use ${EROOT}, however if the main tree does not use ${ROOT}, we only add the offset, ${EPREFIX}.

This rule basically means that you never add ${EROOT} yourself, if there isn't a ${ROOT} in the main tree ebuild. Repeating: whether or not that is "correct", for Gentoo Prefix this rule always holds. Rationale is simple: if it is a bug, it is a bug that should be fixed "upstream" (in the main tree), and that fix propagated to Gentoo Prefix. We don't want any extra differences between main tree and Gentoo Prefix, to keep maintenance and the amount of unrelated changes low.

My question is, does this apply in this case? From quickly scanning I think these rules only apply to ebuilds being modified by the Gentoo Prefix folks and not ebuilds being modified in the main tree. Am I correct in saying this? If so, I have a solution for this issue with mpfr that uses EROOT, if not, well, I'm not sure how to fix this problem.

On a semi-tangent, I found this in the definition of econf in /usr/lib64/portage/bin/phase-helpers.sh (I went looking for this code when I saw some odd paths on the configure output):
Code:
   if [ -e "${EPREFIX}"/usr/share/gnuconfig/ ]; then
      find "${WORKDIR}" -type f '(' \
      -name config.guess -o -name config.sub ')' -print0 | \
      while read -r -d $'\0' x ; do
         __vecho " * econf: updating ${x/${WORKDIR}\/} with ${EPREFIX}/usr/share/gnuconfig/${x##*/}"
         cp -f "${EPREFIX}"/usr/share/gnuconfig/"${x##*/}" "${x}"
      done
   fi

This code updates config.guess and config.sub for the package based on what it finds at ${EPREFIX}/usr/share/gnuconfig/ . That would be nice and dandy normally, but for cross-compilation... this doesn't seem right for the same reasons mpfr is failing to compile. Thankfully (or perhaps dangerously) there isn't a difference between /usr/share/gnuconfig and /usr/armv6zk-hardfloat-linux-gnueabihf/usr/share/gnuconfig on my system, but what if there were?
Back to top
View user's profile Send private message
gemarcano
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jun 2012
Posts: 100
Location: California

PostPosted: Mon Oct 14, 2013 6:13 pm    Post subject: Reply with quote

Here are my proposed changes for the mpfr ebuild, assuming it's OK to change EPREFIX for EROOT:
Code:
diff --git a/usr/portage/dev-libs/mpfr/mpfr-3.1.2-r1.ebuild b/usr/local/portage/dev-libs/mpfr/mpfr-3.1.2-r1.ebuild
index 1988c85..493b45e 100644
--- a/usr/portage/dev-libs/mpfr/mpfr-3.1.2-r1.ebuild
+++ b/usr/local/portage/dev-libs/mpfr/mpfr-3.1.2-r1.ebuild
@@ -46,8 +46,8 @@ src_prepare() {
 src_configure() {
        econf \
                --docdir="${EPREFIX}"/usr/share/doc/${PF} \
-               --with-gmp-lib="${EPREFIX}"/usr/$(get_libdir) \
-               --with-gmp-include="${EPREFIX}"/usr/include \
+               --with-gmp-lib="${EROOT}"/usr/$(get_libdir) \
+               --with-gmp-include="${EROOT}"/usr/include \
                $(use_enable static-libs static)
 }

Using this ebuild successfully cross-compiles mpfr on my system.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Mon Oct 14, 2013 9:49 pm    Post subject: Reply with quote

ROOT refers to the area where the package will be installed. It happens to work here because you are installing the cross-compiled binary in the same area on the host as all the other cross-compiled packages you built previously. This is almost always the case for both native and cross-compile users. As I read man 5 ebuild, build time dependencies are installed into ROOT, so your solution seems correct.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum