* [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 @ 2013-09-05 21:17 Richard Purdie 2013-09-06 7:08 ` Khem Raj 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2013-09-05 21:17 UTC (permalink / raw) To: openembedded-core 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.purdie@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 + # 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 done } ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 2013-09-05 21:17 [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 Richard Purdie @ 2013-09-06 7:08 ` Khem Raj 2013-09-06 9:34 ` Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: Khem Raj @ 2013-09-06 7:08 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On Sep 5, 2013, at 2:17 PM, Richard Purdie <richard.purdie@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.purdie@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. > > + # 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 > done > } > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 2013-09-06 7:08 ` Khem Raj @ 2013-09-06 9:34 ` Richard Purdie 2013-09-06 16:54 ` Khem Raj 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2013-09-06 9:34 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On Fri, 2013-09-06 at 00:08 -0700, Khem Raj wrote: > On Sep 5, 2013, at 2:17 PM, Richard Purdie <richard.purdie@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.purdie@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 2013-09-06 9:34 ` Richard Purdie @ 2013-09-06 16:54 ` Khem Raj 2013-09-06 17:05 ` Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: Khem Raj @ 2013-09-06 16:54 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On Sep 6, 2013, at 2:34 AM, Richard Purdie <richard.purdie@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.purdie@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.purdie@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. > >>> >>> + # 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… yeah. I dont think we have much choice there. re-autoconfiguring gcc with different libtool is a project in itself. GCC does not recommend to reconfigure so thats fine. > > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 2013-09-06 16:54 ` Khem Raj @ 2013-09-06 17:05 ` Richard Purdie 2013-09-06 21:06 ` Khem Raj 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2013-09-06 17:05 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On Fri, 2013-09-06 at 09:54 -0700, Khem Raj wrote: > On Sep 6, 2013, at 2:34 AM, Richard Purdie <richard.purdie@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.purdie@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.purdie@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. Cheers, Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 2013-09-06 17:05 ` Richard Purdie @ 2013-09-06 21:06 ` Khem Raj 2013-09-06 21:09 ` Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: Khem Raj @ 2013-09-06 21:06 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On Sep 6, 2013, at 10:05 AM, Richard Purdie <richard.purdie@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.purdie@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.purdie@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.purdie@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. > > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 2013-09-06 21:06 ` Khem Raj @ 2013-09-06 21:09 ` Richard Purdie 2013-09-06 21:18 ` Khem Raj 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2013-09-06 21:09 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On Fri, 2013-09-06 at 14:06 -0700, Khem Raj wrote: > On Sep 6, 2013, at 10:05 AM, Richard Purdie <richard.purdie@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.purdie@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.purdie@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.purdie@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 2013-09-06 21:09 ` Richard Purdie @ 2013-09-06 21:18 ` Khem Raj 0 siblings, 0 replies; 8+ messages in thread From: Khem Raj @ 2013-09-06 21:18 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core On Fri, Sep 6, 2013 at 2:09 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > I can't see how that will help solve this problem though? might help n getting the libtool hackery right. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-09-06 21:18 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-09-05 21:17 [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8 Richard Purdie 2013-09-06 7:08 ` Khem Raj 2013-09-06 9:34 ` Richard Purdie 2013-09-06 16:54 ` Khem Raj 2013-09-06 17:05 ` Richard Purdie 2013-09-06 21:06 ` Khem Raj 2013-09-06 21:09 ` Richard Purdie 2013-09-06 21:18 ` Khem Raj
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox