[OE-core] [PATCH RFC] gcc-runtime: Hacks for libgfortran with gcc-4.8

[Khem Raj]

On Sep 6, 2013, at 2:34 AM, Richard Purdie <richard.purdie at 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 at 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 at 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
>