[ELDK] Fix libtool-cross do_qa_configure error

[Larry Baker]

Detlev, et al.,

I need your advice about how to proceed.

As I mentioned before, though I now have an ARMV5TE gfortran cross compiler, it does not function.  When I compile a program, it fails at the link step:

> arm-linux-gnueabi-gfortran: error: libgfortran.spec: No such file or directory.

This is true; there is no libgfortran.spec file produced by the bitbake gcc-cross build.

I have built an ARMV5TE gfortran cross compiler before.  In the installation directory tree there are several libgfortran.* files, including three libgfortran.spec files.

I found the bitbake gcc-cross recipe make "install" command is defined in meta/recipes-devtools/gcc/gcc-package-cross.inc.  However, unlike the gfortran installl command I used, "make install", bitbake uses "make install-host".

I read the gcc-cross Makefile to find out the difference.  The install target has dependencies on both install-host and install-target.  So, the difference is my install also did a "make install-target".

I experimented using my gfortran Makefile.  When I do a "make install-host", there are no libgfortran.* files installed.  When I do a "make install", there are many libgfortran.* files.  The same is true if I do a "make install-target", or a "make install-target-libgfortran".  (All these commands were done to a non-existent installation directory; I did an \rm -r -f before each one.)

My quandry is: is this a bug in Open Embedded, or in the GCC Makefile?  I actually think the latter, if "make install-host" is intended to produce a functioning compiler.  (arm-linux-gnueabi-gcc and arm-linux-gnueabi-g++ work to compile he rest of my application.)  I also think there might be a bug in Open Embedded, which is, what is the point of doing "make install-host" and not "make install"?  The make produces a cross compiler when run by gcc-cross.  Why shouldn't both the install-host and install-target make targets be executed?  What does a cross make create that is not useful?

Should I complain to both mailing lists?

Do you think there will be any harm if I change the gcc-package-cross.inc to run "make install"?  The only other alternative I can think of is to modify it to do a "make install-target-libgfortran" if FORTRAN != "".  I suppose there could be trouble if there was a good reason for the "make install-host".  There are no comments in gcc-package-cross.inc saying why that was done as a caution.

Thank you,

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov




On Aug 27, 2013, at 3:46 AM, Detlev Zundel wrote:

> Hi Larry,
> 
> [...]
> 
>> These patches define the FC variables and update the default FORTRAN from f77 to fortran:
> 
> Thanks for looking into this topic!
> 
>> --- original/eldk/meta/classes/native.bbclass
>> +++ patched/eldk/meta/classes/native.bbclass
>> @@ -61,2 +61,3 @@
>> export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}"
>> +export FC = "${CCACHE}${HOST_PREFIX}gfortran ${HOST_CC_ARCH}"
>> export F77 = "${CCACHE}${HOST_PREFIX}g77 ${HOST_CC_ARCH}"
>> --- original/eldk/meta/conf/bitbake.conf
>> +++ patched/eldk/meta/conf/bitbake.conf
>> @@ -448,2 +448,3 @@
>> export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>> +export FC = "${CCACHE}${HOST_PREFIX}gfortran ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>> export F77 = "${CCACHE}${HOST_PREFIX}g77 ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
>> @@ -463,2 +464,3 @@
>> export BUILD_CXX = "${CCACHE}${BUILD_PREFIX}g++ ${BUILD_CC_ARCH}"
>> +export BUILD_FC = "${CCACHE}${BUILD_PREFIX}gfortran ${BUILD_CC_ARCH}"
>> export BUILD_F77 = "${CCACHE}${BUILD_PREFIX}g77 ${BUILD_CC_ARCH}"
>> --- original/eldk/meta/recipes-devtools/gcc/gcc-configure-common.inc
>> +++ patched/eldk/meta/recipes-devtools/gcc/gcc-configure-common.inc
>> @@ -13,3 +13,3 @@
>> # gcc 3.x expects 'f77', 4.0 expects 'f95', 4.1 and 4.2 expect 'fortran'
>> -FORTRAN ?= ",f77"
>> +FORTRAN ?= ",fortran"
>> LANGUAGES ?= "c,c++${FORTRAN}${JAVA}"
>> 
>> I know DENX is working on an update for the ELDK-5.4.  I hope there is time to include these patches.
> 
> If we can get this to work correctly, we'll of course include them.
> 
>> Should I also forward these patches to the Yocto Project?  To the Open
>> Embedded Project?  I don't know exactly who your upstream provider is.
> 
> Yes, we want to fix these (non-ELDK related) issues in the proper
> upstream.  Although our upstream is Yocto, that project itself
> consists of oe-core[1] and the Yocto sepcific extensions.  Personally I'd
> say, this belongs into the oe-core area and therefore should be
> discussed on that mailing list[2].
> 
> Cheers
>  Detlev
> 
> [1] https://www.yoctoproject.org/tools-resources/projects/openembedded-core
> [2] http://lists.openembedded.org/pipermail/openembedded-core/
> 
> -- 
> It is practically impossible to teach good programming to students that have
> had a  prior exposure to BASIC:  as potential  programmers they are mentally
> mutilated beyond hope of regeneration.                    -- Edsger Dijkstra 
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de