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.
>
>>>
>>> + # 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
>
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
