[ELDK] Fix libtool-cross do_qa_configure error
Larry Baker
baker at usgs.gov
Sat Aug 31 07:54:58 CEST 2013
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
baker at usgs.gov
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
> 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
>
More information about the eldk
mailing list