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 [email protected] 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: [email protected] _______________________________________________ eldk mailing list [email protected] http://lists.denx.de/mailman/listinfo/eldk
