Created attachment 1452 [details]
Fixes to build a gfortran cross compiler and the gfortran runtime libraries

The patches I submitted are enough to build a gfortran cross compiler, but not enough to to obtain a functional one.  The link step fails with the error:

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

An additional recipe file has to be modified.  I have attached my complete patch file with fixes for four recipe files.  (The patches I have attached are made to the openembedded git sources.  I actually use the DENX Yocto/ELDK distribution.)

I now have a functional gfortran cross compiler.  I have yet to actually run anything on my target.  I have not yet properly prepared a rootfs.

After applying the patches 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

Because I do not understand enough about bitbake, there are still four warning 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

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.

It would be really nice if 1) someone could figure out how to properly specify the DEPENDS and REQUIRES, and 2) better yet, implement a gfortran.bb recipe that raises an ENABLE_FORTRAN flag for the actual changes that must occur inside the recipes I had to override with bbappends.  There should be some way to add the DEPENDS on gfortran to libgfortran.  As it is, you have to figure out that libgfortran fails if there is no gfortran, and that takes knowing how to modify the gcc-cross.bb recipe.

None of the steps to enable fortran support are obvious at all, and they are kind of messy -- you have to know too much about the bowels of the gcc and gcc-runtime recipes to properly enable fortran support.

Firstly, please note that we don't officially support fortran so it isn't something high up on our radar. That said, I'd posted three patches to the OE-Core mailing list which make things build cleanly in master. There is one patch showing example enablement from local.conf, one patch fixing the packaging and another with hacky fixes to make libgfortran build in gcc-4.8. It would appear gcc 4.7 is easier from your patches.

I'm hoping to merge the first two patches and then resolve this bug since the process would then be clearer. I would add that the dependencies are taken care of by the system already, there is no need to add any link between gfortran and libgfortran or anything like that.

Richard,

Please let me know how I can help test what you've done.  Should I look on the OE-core mailing list for your patches?  If they are already merged in some git tree, where should I grab them?

I don't quite understand the relationship between Yocto and OpenEmbedded.  I know there are parts of the OE git that are not in the Yocto distribution.  So, when you say "we don't officially support fortran", I don't know exactly who the "we" is.  I would make a request that the fortran machinery be supported, and in a cleaner way (my preference would be with its own gfortran-cross.bb and gfortran.bb), if I knew who to ask.

You mention trouble building gfortran-4.8.  I have built gfortran on several platforms in the past.  I vaguely remember some problem with 4.8 myself.  Have you fixed whatever was wrong?  If not, I can try to find old notes where I might have run into the same problem and already fixed it.  (My vague recollection was some bug due to GCC shifting to C++ for their base language.  I think this affected the linking of gfortran programs, not building the gfortran comiler.)

As far as the dependencies, when I enabled building libgfortran for the target (my gcc-runtime...bbappend), and added libgfortran to the list of installed packages, bitbake did not pick up the dependency in gcc-runtime for a cross-gfortran.  I think the gcc-runtime configure step failed, or else the compile, since libgfortran needs a cross-gfortran.  I had to also enable building a cross-gfortran (my gcc-cross...bbappend).  Did you make some change that would cure that?

Thanks,

Larry Baker

Richard,

Here's a link to the problems I had a year ago with gcc 4.8:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630

With the configure options I tried to use, I ran into this:

Undefined symbols:
  "___cxa_guard_acquire", referenced from:
      coalesce_ssa_name()     in libbackend.a(tree-ssa-coalesce.o)
  "___cxa_guard_release", referenced from:
      coalesce_ssa_name()     in libbackend.a(tree-ssa-coalesce.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

It turned out that my configure options caused a C++ link to be done using the gcc driver instead of the g++ driver.  Because the gcc driver does not bring in all the necessary C++ support unless explicitly told to do so (by design), the link step failed.

Larry Baker

Richard,

I viewed your PATCH posts at lists.openembedded.org.  I am pleased with how comprehensive your fixes are for the gcc-runtime libraries.  I would probably have punted on the 4.8 gfortran mess.  At that point, I would have just switched back to my own ARM cross 4.8 gfortran build.

I do request that you consider applying the fixes I sent that export CROSS_FC/FC within the OE-core.  These would be the patches I sent in my initial post.  That would remove the need to add the export BUILD_FC/FC lines in your conf example.  Though I did not suggest it, I think you might also take this opportunity to remove the export CROSS_F77/F77 cruft.

I see from your example that you are more clever than I was in inserting the variable definitions where they are needed instead of using .bbappend files.  You know your way around bitbake much better than I.

Would you help if I try out your patches?  Or, have you already done that?

Thank you for your efforts.

Larry Baker

Richard,

I noticed your remarks about not being a fan of Fortran.  And, the preface to the conf example that Fortran is not officially supported.  As a very happy Fortran programmer and user, it is a bit disappointing.

Let me propose to you a use case for Fortran in an embedded Yocto/OE system.

We run lots of simulations and do lots of signal analysis on our Intel x86_64 computing cluster.  Those applications are written in C, C++, and Fortran.  I've been interested in utilizing low power ARM processors, along with either GPUs or FPGAs or DSPs.  (I've seen pre-? announcements of ARM-based cluster hardware.  H-P and Dell, maybe?)  It makes a great deal of sense to me to run as stripped-down and lightweight an O/S as possible.  We would need cross-compilers and runtime libraries for all three languages, plus scripting languages like Perl and python, maybe Java (not a requirement at this time).  Yocto/OE seems like a very good candidate for that application.

Our immediate use case however is less sexy.  We want to be able to extract information from our data nearer in space and time to where it is generated.  That is affordable only if the computing platforms are inexpensive, and can be run off battery power.  That is possible with ARM SoC systems.  I like the idea of building a customized system from scratch.  Yocto/OE should work well.  But, only if we can port our Fortran applications as well as our C and C++ and Java applications.  My other choice has been ArchLinuxARM, which can self host development in all those languages.  But, the really inexpensive platforms we could use are too small (not enough flash) to run ArchLinuxARM.  Thus, my experimentation with Yocto/OE.

I'd like to propose Yocto/OE to my managers as part of a future solution for us.  That will be easier if our Fortran applications can be a part of that.

Thank you,

Larry Baker

It also occurs to me that I saw several requests to build Fortran with bitbake on the BeagleBone mailing list.  BeagleBone comes with an Angstrom/OE rootfs.  OE support for Fortran would be helpful to the BeagleBone community.

This includes us.  We are looking at BeagleBone Black as a ppotential platform.  I have to decide whether Angstrom/OE Linux or ArchLinuxARM makes more sense for us on that platform.  ArchLinuxARM comes with libgfortran.so pre-loaded.  It is very easy for us to use my existing ARM cross gfortran compiler to target ArchLinuxARM systems.  I don't think anyone has been able to do that for Angstrom/OE Linux yet.

Larry Baker

There is now documentation merged:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=835b5c1504d2edc415143e9bae981290e457d82a
and packaging fixes:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=95d413d03f66299aa7a835e84dd8ce00d623da6d

Can someone please address the issue about who decides what level of support Fortran deserves?  How can that policy be influenced?  Do users have a voice?

Why not remove the F77 cruft or replace the F77 exports that still remain with their FC equivalents?  That would have been more helpful to Fortran users.  I don't think there is a prayer that the f77 remnants that are left will work at all.  They are just debris.

Larry Baker

Created attachment 1581 [details]
error output

Building gcc-runtime with the following in local.conf:

FORTRAN_forcevariable = ",fortran"
RUNTIMETARGET_append_pn-gcc-runtime = " libquadmath libgfortran"
export BUILD_FC = "${CCACHE}${BUILD_PREFIX}gfortran ${BUILD_CC_ARCH}"
export FC = "${CCACHE}${HOST_PREFIX}gfortran ${HOST_CC_ARCH}"

works on qemuarm but fails on qemux86 and qemux86-64 (see attached).

Larry: Sorry, I didn't see the comments in here for some reason.

The decision on what to officially support is based on input from the community but also on the availability of build/testing infrastructure. The larger amount of things we officially support, the greater the testing matrix we have. It also means we have more bug reports and that means needing more people to work on those reports.

Don't read much into my comments about fortran, I admit its not my favourite language but I did at least try and sort out the build for you.

I didn't realise we could drop the F77 parts and replace them with the FC ones. You make a good argument for doing that, perhaps you could send a patch to the mailing list to do that?

Regarding the qemux86-64 build failure, I'm not sure how to cleanly fix it. I obviously have a hacky patch to do it but I couldn't come up with anything that I'd consider as a clean solution. Are you able to help refine/improve the patch?

Now we're post release, we have a bit more freedom to make changes so we should look at the F77/FC part at least.

Iin case it isn't clear to get official fortran support we'd need someone to step up and own the fortran issues and resolve any compilation problems in a timely manner. I'm not sure you'd be able to provide that commitment though?

Richard,

Thank you for your reply.  I will take a look at creating a F77->FC patch from the current git source tree.  It should be virtually identical to what I first posted (all I have to do is delete the F77 stuff I left alone).

I am pleased that the door is not shut on the future for Fortran in Yocto.  Not having the resources to fix problems is understandable.  That at least means Fortran issues can still be collected and may eventually get fixed.  Even though you think you have just hacked a solution together, I learned from you a better way to add Fortran using local.conf compared to my .bbappend method.

You are right, though, that I am not able to be a Yocto/Fortran support resource.  For example, I don't use Ubuntu; I use CentOS.  I am a novice Yocto user.  I stumbled upon ELDK/Yocto while searching for a minimal rootfs suitable for my ARMV5TE target.  And, I am naive when it comes to all the build options and hidden environment variables that have to be set up properly to do cross builds of cross compilers.  I was not even aware that the gfortran compiler could be built separately from the run-time libraries.  I've always added (cross) gfortran to an existing system, and I built everything in one "make".

I am catching up still from being furloughed during the US Government shutdown.  I should be able to make up the F77->FC patch for you next week.

Larry Baker

Finally got these issues resolved in master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cae2315266b704614fe1d7bdeef004ef67a01e8d