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

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

[Richard Purdie]

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
 }
 

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

[Khem Raj]

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
> }
> 
> 
> 
> 

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

[Richard Purdie]

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

Re: [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@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
> 

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

[Richard Purdie]

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

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

[Khem Raj]

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
> 

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

[Richard Purdie]

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

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

[Khem Raj]

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.