sysroot | Work in Progress may eat your cat | Machine Learning library

Thanks to Tsyvarev comment the solution was to remove the -lOBD2 from the target_link_options. As per Tsyvarev suggestion now all the linker options are linked through target_link_libraries.

The solution to the CMakeLists.txt

The problem was writing to FLASH memory - it hasn't been correctly initialized.

The proper way to write to flash on MPC5748g using the SDK 3.0.3 is following:

• save flash controller cache
• initialise flash
• check and protect UT block
• unblock an address space
• erase a block in this space
• check if the space block is blank
• program the block
• verify if the block is programmed correctly
• check sum of the programmed data
• restore flash controller cache

The strange behaviour of printf and pointer was due to compiler optimization. After changing the compiler flags to -O0 (no optimization), the error was consistent.

The same consistent error can be achieved when marking the pointers as 'volatile'.

I found out it has been resolved in

https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a74428921f8bfb33cbe0340bfd810b6945e432d2#patch1

and it works fine in ffmpeg 5.0. You can also apply this patch to 4.4.

Had the same problem. the /lib you want to copy is a link, not a folder. It's linked to /usr/lib. So try it with

The output means that make invoked this command:

Just to share, not sure it will help you. However it shows that in standard conditions it is possible to use the conda gcc as described in the documentation instead of the system gcc.

/home/MY_USER/.../sysroots-uninative/x86_64-linux/lib/libc.so.6: version 'GLIBC_2.32' not found (required by /lib64/libgomp.so.1)

You are mixing system libgomp.so.1 with sysroot libc.so.6 -- this will never end well. You probably need to build libgomp.so.1 in the sysroot as well.

And if I run /lib/libc.so.6, I get:

That is irrelevant -- you link isn't failing with that library, but with the sysroot one.

If you run /home/MY_USER/path/Project/xilinx-zc702-2018.2/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6, you'll see that it is in fact too old (older than 2.32).

After a few days of debugging, I figured out there problem. If anyone with more knowledge than I on linking would like to chime in to add things, please do. Ultimately, this was resolved by using gcc as the linker as opposed to using ld (the ones provided by yocto's cross compiler; i.e. aarch64-poky-linux-gcc).

In order to do this, I modified my recipe to pass in LD=${CC} LDFLAGS=${LDFLAGS} to my Makefile. Now, it builds and executes properly for both the RPi and OrangePi targets.

I believe this is mainly the case because the LDFLAGS provided by yocto actually can't be parsed by ld. From my research, it looks like ld is typically invoked by gcc. However, the flags still need to get to the complier. So, originally, LDFLAGS that needed to be passed into linking, weren't being passed in at all because I just assumed there was an error with doing it that way. So, be sure you're passing your LDFLAGS that yocto gives you into gcc.

Yes there was a change in behaviour.

In C you are supposed to only define a global variable in one translation unit, other translation unit that want to access the variable should declare it as "extern".

In your code, a.h is included in both a.c and main.c so the variable is defined twice. To fix this you should change the "int test" in a.h to "extern int test", then add "int test" to a.c to define the variable exactly once.

In C a definition of a global variable that does not initialise the variable is considered "tentative". You can have multiple tentative definitions of a variable in the same compilation unit. Multiple tentative defintions in different compilation units are not allowed in standard C, but were historically allowed by C compilers on unix systems.

Older versions of gcc would allow multiple tenative definitions (but not multiple non-tentative definitions) of a global variable in different compilation units by default. gcc-10 does not. You can restore the old behavior with the command line option "-fcommon" but this is discouraged.