On Fri, 2013-09-06 at 14:06 -0700, Khem Raj wrote:
> On Sep 6, 2013, at 10:05 AM, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
>
> > On Fri, 2013-09-06 at 09:54 -0700, Khem Raj wrote:
> >> On Sep 6, 2013, at 2:34 AM, Richard Purdie
> >> <richard.pur...@linuxfoundation.org> wrote:
> >>
> >>> 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.
> >>
> >> But we stash the build artifacts from gcc-cross that then we reuse to
> >> build gcc-runtime so I am hoping that
> >> it will do the configuration bits right probably and we dont have to do
> >> libtool surgery.
> >
> > It won't help, we'd have to install the libs/headers from quadmath into
> > the target sysroot and we can't reasonably do that from the cross
> > recipe.
>
> I was thinking just to have configured tree like we have for libgcc
> and others. full build of libquadmath and libgfortran
> of course happens with gcc-runtime phase.
I can't see how that will help solve this problem though?
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
