On Fri, 2013-09-06 at 00:08 -0700, Khem Raj wrote:
> On Sep 5, 2013, at 2:17 PM, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
>
> > These are the hacks I needed to make libgfortran build. This is ugly, no
> > argument from me. We could probably get better results if we patch
> > configure and libtool to stop doing nasty things. I've probably taken
> > this as far as I'd want to though, not being a particular fan of
> > fortran...
> >
> > Khem: Any thoughts on this?
> >
> > Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
> > ---
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > index 2599760..395623f 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > @@ -18,6 +18,9 @@ RUNTIMETARGET = "libssp libstdc++-v3 libgomp"
> > # libmudflap
> > # libgfortran
> >
> > +DEPENDS_append = " chrpath-replacement-native"
> > +EXTRANATIVEPATH += "chrpath-native"
> > +
> > do_configure () {
> > export CXX="${CXX} -nostdinc++ -nostdlib++"
> > mtarget=`echo ${MULTIMACH_TARGET_SYS} | sed -e s#-${SDKPKGSUFFIX}##`
> > @@ -30,6 +33,11 @@ do_configure () {
> > cd ${B}/$target/$d/
> > chmod a+x ${S}/$d/configure
> > ${S}/$d/configure ${CONFIGUREOPTS} ${EXTRA_OECONF}
> > + # Ugly hack, libgfortran configure looks for
> > ../libquadmath/libquadmath.la
>
> Maybe we should explicitly --enable-libquadmath in gcc-cross when fortran is
> asked for in RUNTIMETARGETS
> might avoid some of below.
That would mean the gcc-cross recipe has to package it. We've basically
now agreed and changed the code so all the packaging doesn't happen in
-cross packages since it was always problematic.
FWIW I also tried disabling quadmath but that caused different build
failures.
> >
> > + # so we need to compile it before configure
> > + if [ "$d" = "libquadmath" ]; then
> > + oe_runmake MULTIBUILDTOP=${B}/$target/$d/
> > + fi
> > done
> > }
> >
> > @@ -38,6 +46,16 @@ do_compile () {
> > for d in libgcc ${RUNTIMETARGET}; do
> > cd ${B}/$target/$d/
> > oe_runmake MULTIBUILDTOP=${B}/$target/$d/
> > + if [ "$d" = "libgfortran" ]; then
> > + # libtool needs libdir to match the final installation
> > directory which configure
> > + # sets from output from this command (e.g. both set to
> > /usr/lib/../lib
> > + # It also adds bogus RPATHS which we have to delete
> > + fulllibdir=`$CC -print-multi-os-directory`
> > + if [ $fulllibdir != "." ]; then
> > + sed -i -e
> > "s#relink_command=.*#relink_command=#" ${B}/$target/$d/libgfortran.la
> > + chrpath -d `readlink -f
> > ${B}/$target/$d/.libs/libgfortran.so`
> > + fi
> > + fi
>
> hmm remind me but I think we use unmodified libtool that comes with gcc IIRC.
> if we used libtool-cross then this could
> be fixed there
We do use libtool from gcc, yes. To do otherwise safely, you have to
reautoconf gcc which "is painful". Mixing two libtool versions usually
gives stacks of errors so our only option would be to patch libtool in
gcc to apply our patches. Even then, I'm not sure they'd cope with the
way quadmath is linked :/.
This is why I ended up hacking things in the metadata since it seemed
the least worse solution...
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
