Detlev, et al.,
I have succeeded in building a functional gfortran cross compiler. I have yet
to actually run anything on my target. I'll add an update to confirm
everything works.
One more recipe file had to be modified:
meta/recipes-devtools/gcc/gcc-package-runtime.inc.
I submitted the first part I of the fix to the openembedded-core mailing list,
but I have received no response. Today I posted a bug report and the first
part of the fix to the Yocto bugzilla web site. I've heard nothing from them
either. I'll post my final patch file to both of them. (One file name
changed, and the line numbers changed for the OE patches, but the content is
the same as these patches, which are for Yocto/ELDK.) Even if they do not
include the patches in time for your next ELDK release, I hope you will include
them in your distribution.
Because I do not understand enough about bitbake, there are still four warnings
messages from the build:
> WARNING: QA Issue: gcc-runtime: Files/directories were installed but not
> shipped
> /usr/lib/gcc/arm-linux-gnueabi/4.7.2/libgfortranbegin.la
> /usr/lib/gcc/arm-linux-gnueabi/4.7.2/libcaf_single.la
> /usr/lib/gcc/arm-linux-gnueabi/4.7.2/libcaf_single.a
> /usr/lib/gcc/arm-linux-gnueabi/4.7.2/libgfortranbegin.a
Plus, I tried to add DEPENDS and REQUIRES to the .bbappend recipes I needed to
build gfortran, but they caused the build to fail. So, I commented them out.
After applying the patches below to the Yocto/ELDK git tree, I added the
following files to build gfortran and install libgfortran.so on the target
rootfs:
• meta-eldk/recipes-extended/images/core-image-at91sam9g20ek.bb
> DESCRIPTION = "A console-only basic image customized for AT91SAM9G20-EK."
>
> IMAGE_FEATURES += "ssh-server-openssh"
>
> IMAGE_INSTALL = "\
> packagegroup-core-boot \
> packagegroup-core-basic \
> chkconfig \
> ntp \
> libgfortran \
> "
>
> EXTRA_IMAGE_FEATURES = ""
>
> inherit core-image
• meta-eldk/recipes-devtools/gcc/gcc-cross_4.7.bbappend
> # Build a gfortran cross-compiler
> FORTRAN = ",fortran"
> #PROVIDES += "virtual/${TARGET_PREFIX}gfortran"
• meta-eldk/recipes-devtools/gcc/gcc-runtime_4.7.bbappend
> # Build the libgfortran run-time library
> RUNTIMETARGET += "libgfortran"
> #DEPENDS += "virtual/${TARGET_PREFIX}gfortran"
My bitbake command is
> $ MACHINE=generic-armv5te bitbake -k core-image-at91sam9g20ek
Larry Baker
US Geological Survey
650-329-5608
[email protected]
Here's my complete eldk-5.4-fortran.patch file:
>>>>> snip <<<<<
--- 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}"
--- /opt/git/eldk/meta/recipes-devtools/gcc/gcc-package-runtime.inc
+++ /opt/git/eldk/meta/recipes-devtools/gcc/gcc-package-runtime.inc
@@ -13,2 +13,3 @@
libgfortran-dev \
+ libgfortran-staticdev \
libmudflap \
@@ -56,5 +57,11 @@
FILES_libgfortran-dev = " \
- ${libdir}/libgfortran.a \
+ ${libdir}/libgfortran.spec \
${libdir}/libgfortran.so \
- ${libdir}/libgfortranbegin.a"
+ ${libdir}/libgfortran.la \
+ ${libdir}/libgfortranbegin.la \
+ ${libdir}/libcaf_single.la"
+FILES_libgfortran-staticdev = " \
+ ${libdir}/libgfortran.a \
+ ${libdir}/libgfortranbegin.a \
+ ${libdir}/libcaf_single.a"
>>>>> snip <<<<<
On Aug 28, 2013, at 9:39 PM, Larry Baker wrote:
> 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
