On Wed, Jan 9, 2019 at 8:17 AM Sergio Paracuellos
<sergio.paracuel...@gmail.com> wrote:
>
> Hi all,
>
> I am trying to compile a complete system with fortran support using
> yocto and I am having problems cross compiling libgfortran. The target
> architecture is arm64 because the system will run in a xilinx mpsoc
> based board. I need fortran support to compile lapack, openblas, scipy
> and other python stuff that seems to need them. The yocto branch I am
> using is the stable 'sumo'. So I do the following for enable fortran
> support:
>
> 1) Add to my local.conf the following line:
> FORTRAN_forcevariable = ",fortran"
> 2) Add a bbappend file for recipes-devtools/gcc/gcc-runtime_7.3.bb with:
> RUNTIMETARGET += "libgfortran"
It seems this RUNTIMETARGET not needed anymore since libgfortran has
now its own recipe.
Setting FORTRAN_forcevariable = ",fortran" in local.conf and adding to the image
the following:
...
FORTRAN_TOOLS = " \
gfortran \
gfortran-symlinks \
libgfortran \
libgfortran-dev \
"
...
IMAGE_INSTALL += " \
...
${FORTRAN_TOOLS} \
...
"
seems to work as it is without any patches. Sorry for the noise.
Best regards,
Sergio Paracuellos
>
> With the branch as it is when gcc-runtime is being build I end up with
> an error because libbacktrace headers can't be found so I have to
> apply the following PATCH to solve this first issue:
>
> diff -Naur gcc-7.3.0/libgfortran/Makefile.in
> gcc-7.3.0.modif/libgfortran/Makefile.in
> --- gcc-7.3.0/libgfortran/Makefile.in 2018-01-25 09:17:54.059232055 +0100
> +++ gcc-7.3.0.modif/libgfortran/Makefile.in 2019-01-08 12:42:00.583138367
> +0100
> @@ -582,7 +582,7 @@
> toolexeclib_DATA = libgfortran.spec
> libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
> libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
> $(srcdir)/libtool-version` \
> - $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
> + $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
> $(HWCAP_LDFLAGS) \
> -lm $(extra_ldflags_libgfortran) \
> $(version_arg) -Wc,-shared-libgcc
> @@ -603,7 +603,7 @@
> -I$(MULTIBUILDTOP)../libgcc \
> -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
> -I$(MULTIBUILDTOP)../libbacktrace \
> - -I../libbacktrace
> + -I../../libbacktrace
>
> But then I get the following error:
>
> |
> /home/sergio/YOCTO/build/tmp/work/aarch64-poky-linux/gcc-runtime/7.3.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
> ../../libbacktrace/.libs/libbacktrace.a(dwarf.o): Relocations in
> generic ELF (EM: 62)
> |
> /home/sergio/YOCTO/build/tmp/work/aarch64-poky-linux/gcc-runtime/7.3.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
> ../../libbacktrace/.libs/libbacktrace.a(dwarf.o): Relocations in
> generic ELF (EM: 62)
> |
> /home/sergio/YOCTO/build/tmp/work/aarch64-poky-linux/gcc-runtime/7.3.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
> ../../libbacktrace/.libs/libbacktrace.a(dwarf.o): Relocations in
> generic ELF (EM: 62)
> | ../../libbacktrace/.libs/libbacktrace.a(dwarf.o): error adding
> symbols: File in wrong format
> | collect2: error: ld returned 1 exit status
> | Makefile:1364: recipe for target 'libgfortran.la' failed
> | make[1]: *** [libgfortran.la] Error 1
> | make[1]: Leaving directory
> '/home/sergio/YOCTO/build/tmp/work/aarch64-poky-linux/gcc-runtime/7.3.0-r0/gcc-7.3.0/build.aarch64-poky-linux.aarch64-poky-linux/aarch64-poky-linux/libgfortran'
> | Makefile:1242: recipe for target 'all' failed
> | make: *** [all] Error 2
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> /home/sergio/YOCTO/build/tmp/work/aarch64-poky-linux/gcc-runtime/7.3.0-r0/temp/log.do_compile.24547)
> ERROR: Task
> (/home/sergio/YOCTO/workspace/poky/meta/recipes-devtools/gcc/gcc-runtime_7.3.bb:do_compile)
> failed with exit code '1'
>
> So It seems that libbacktrace is always built for my host architecture
> instead of for arm64 bits...
> Is this a known problem? Am I doing something wrong?
>
> Thanks in advance for your time.
>
> Best regards,
> Sergio Paracuellos
>
> PD: I updated this info also in a bug related here which seems to be
> fixed https://bugzilla.yoctoproject.org/show_bug.cgi?id=12394
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
