VF50 cortexa5thf-neon vs cortexa5t2hf-neon

Technical Support
, ,
1

Hi,

we were actually updating our yocto to a newer version (From sumo to dunfell). This lead us to the following problem.

We use a own machine configuration derived from the colibri_vf.conf machine defined in meta-freescale-3rd party. In both yocto versions we set in machine configuration:

DEFAULTTUNE  = "cortexa5thf-neon"

In yocto sumo that leads to a toolchain

.../build/tmp/work/cortexa5hf-neon-poky-linux-gnueabi

But in the newer dunfell system this leads to

.../build/tmp/work/cortexa5t2hf-neon-poky-linux-gnueabi

And this where our problem begins. We get a precompiled library without -fPIC that fails at linking time.

relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC

Any idea how to tweak yocto that the same toolchain is used in the newer yocto version?

Any hints are welcome, maybe I don’t got the problem right and it’s somehow else to resolve.

Kind regards,

Sebastian

2

Hi @seho85,

Thanks for using the Toradex Community.

We are currently looking into your question.

Best Regards
Kevin

3

Thanks for effort. I made a little progress.

I thought the actual problem was the toolchain. But I managed to get the right toolchain. I don’t know if the generated image would boot up, because I just tried to build the recipe with linkage error from above.

I excplicit set
TUNE_PKGARCH=“cortexa5hf-neon”
in the machine config instead of letting yocto implicitly set the TUNE_PKGARCH.

The generated the right toolchain folder.
tmp/work/cortexa5hf-neon-poky-linux-gnueabi

But the error at linking error still exists.

And I think it’s because an older glibc was used for generating the precompiled static library we were trying to use

For now I’ll try if I can manage to get it build with a newer glibc.

God damn - I hate proprietary software :confused:

Kinds regards,
Sebastian

4

Hi @seho85

I’m unsure where the issue is.

I would try these things first:

  • Forcing the bfd linker, i.e. add ‘“-fuse-ld=bfd”’ to the linker flags when linking your code. Maybe the bfd linker can cope better with that relocation.

  • Building your code with the ARM instruction set (i.e. not using the default thumb2), in your recipe(s) set DISTRO_ARM_INSTRUCTION = “arm”.

  • Compile the image with the ARM instruction set (i.e. not using the default thumb2), in local.conf set DISTRO_ARM_INSTRUCTION = “arm”. Note that this will rebuild everything.

If that doesn’t help, could you provide a bit more of the error message, i.e. what object file does contain the relocation, is this under your control or from the library you have in binary only?

Max

5

Hi,

i tried your suggestions. First of all - none has worked. Error is still the same.

Setting DISTRO_ARM_INSTRUCTION in local.conf doesn’t trigger a whole rebuild. Error message is still the same.

Don’t wonder that the relocation now happens against another library. I reduced the recipe which produced the error to a bare minimal. I hoped that the error was produced by our “bigger” project, but the error is still the same in the reduced project.

We got a static library that contains proprietary software we bought and on delivery we got a bunch of headerfiles and that static library. libeclr.a.

We created an autotools project that uses that library, and in yocto sumo it has worked, but yocto sumo contains an older glibc. And thats what I think were the error is coming from.

I attached the errors provided by bitbake when building the recipe.

compile_error_with_arm_instruction_in_recipe

compile_error_with_fuse_ld_bst

compile_error_without_tweaks

It would been nice, if the older proprietary software has worked in the new yocto system, cause we were able to generate a new “firmware release” for the devices which were running the software. But my main task was to update the yocto system for usage with another proprietary software (that basically does the same, but from another vendor).

I’ll try to run the created binary from the yocto-sumo (older glibc) using the image generated by newer yocto system. Maybe that works. I also found another article in the web which mentioned patching the binary weakening the symbols a.s.o., but that currently beyond my abilities. And out of scope of my current work.

If you don’t have any idea how to continue, I will take it as not working.

Thanks again for your effort.

6

Hi

It looks like you do not use our setup to build but rather use a poky setup with only our BSP layers added.
Due to that the way to force the arm instruction set did not work, i.e. you still compile and link with ‘-mthumb’ rather than with ‘-marm’.

Could you retry with ARM_INSTRUCTION_SET = "arm" in your recipe.

As another idea you likely link shared object (with -lohpipc ) which I guess contains code which uses the static library.
Could you compile that one (libohpipc.so) with -fPIC and retry.
Could you compile that one into a static library and link it statically, -Wl,-Bstatic -lohpipc -Wl,-Bdynamic

7

Yep, were not using the toradex bundle because it is unfortunately stuck in yocto rocko (for VF50). And we liked to use some more state of the art software packages. openssl 1.1.1 for example. Bring your bundle to a more recent version of yocto and we will be happy to use it :slight_smile:

I think the outputs could been interpreted a little bit misleading. The libohpipc.so was not used anymore in the code base. I just forgot to remove it from the Automake.am when i reduced the project to a bare minimum. I dropped it an recompiled with ARM_INSTRUCTION_SET = “arm” but the error a pretty much the same.output from yocto

I tried it with also with “-fuse-ld=bfd” but the output is still the same. (Except for the called ld binary)

The function from the static library are just used in the generated binary (pcos_eclr)

Here is the Automake.am for the project, hope that makes project organization a little bit clearer.

AUTOMAKE_OPTIONS = subdir-objects

bin_PROGRAMS = pcos_eclr
pcos_eclr_SOURCES = eclrEnvironment.cpp \
eclrImageFile.cpp \
eclr_main.cpp \
linuxfile.cpp \
threadimpl.cpp 

pcos_eclr_LDADD = -lpthread -lrt /home/sebastian/OHP/yocto-codesys/build/workspace/sources/ohp-pcos-eclr/src/libeclrlib.a


AM_CXXFLAGS = @seb_eclr_CFLAGS@
#AM_LDFLAGS = @seb_eclr_LIBS@ -fuse-ld=bfd
AM_LDFLAGS = @seb_eclr_LIBS@

CLEANFILES = *~
8

@seho85

We actually did change our layers after your report that it does not build for colibri-vf anymore ;-).
However you are also fine with using plain meta-freescale. Mentioning that fact would have helped in answering your questions though.

Some more things to check, apart from making the binary only library provider recompile the static library:

  • Are these relocations really in the binary only library? The cross-objdump program should be able to tell you that:

i.e. `arm-…-objdump -x /home/sebastian/OHP/yocto-codesys/build/workspace/sources/ohp-pcos-eclr/src/libeclrlib.a | grep R_ARM_THM_MOVW

  • Or in one of your source files?
    i.e. `arm-…-objdump -x eclrEnvironment.o eclrImageFile.o eclr_main.o linuxfile.o threadimpl.o | grep R_ARM_THM_MOVW

If it is in your source files, does it help to compile them with ‘-fPIC’

  • Does it work when compiling the full image for arm?

I.e. for a poky setup with ARM_INSTRUCTION_SET = "arm" in e.g. local.conf. (As it did not work with my proposed DISTRO_ARM_INSTRUCTION which is specific to the Toradex BSP)

9

Hi,

sorry for the delay in my answer, I needed to finish some other important stuff in between.

using arm-poky-linux-gnueabi-objdump confirmed showed that R_ARM_THM_MOVW is just used in the libeclrlib.a. The object files generated on build haven’t any “reference” to R_ARM_THM_MOVW.

So -fPIC won’t help.

I also added ARM_INSTRUCTION_SET = “arm” to local.conf and also to the recipe, but the error from the linker still exists.

I noticed a difference between the TUNE_FEATURES displayed when triggering a bitbake task:

In dunfell:

…
TUNE_FEATURES = “arm vfp cortexa5 neon thumb callconvention-hard”
TARGET_FPU = “hard”
…

And in sumo

…
TUNE_FEATURES = “arm armv7a vfp thumb neon callconvention-hard cortexa5”
TARGET_FPU = “hard”
…

I added

TUNE_FEATURES_append = " armv7a"

to the machine config, but now the glibc. The TUNE_FEATURES shown in the “banner” do now contain the same entries.

But the configure task of glibc fails.

…
configure: WARNING:
| *** These auxiliary programs are missing or incompatible versions: msgfmt
| *** some features or tests will be disabled.
| *** Check the INSTALL file for required versions.
| checking LD_LIBRARY_PATH variable… ok
| checking for bash… (cached) /bin/bash
| checking for perl… /home/sebastian/OHP/yocto-codesys/build/tmp/hosttools/perl
| checking for install-info… /home/sebastian/OHP/yocto-codesys/build/tmp/work/cortexa5hf-neon-poky-linux-gnueabi/glibc/2.31+gitAUTOINC+f84949f1c4-r0/recipe-sysroot-native/bin/install-info
| checking for .set assembler directive… yes
| checking linker support for protected data symbol… yes
| checking linker support for INSERT in linker script… yes
| checking for broken attribute((alias()))… yes
| configure: error: working alias attribute support required

I also tried installing gettext in debian, and also adding the i386 version of gettext (which contains msgfmt)

But configure is still complaining about msgfmt.

10

I’ll give up at this point :neutral_face:

Spending more time one this topic doesn’t make much more sense in my opinion.

Thank you for you help @max.tx and @kevin.tx