PROCESSOR-SDK-AM62X: wordsize.h - when using

Hi Andres (mostlikely) when workining with protobufs and attempting to configure the build space I had difficulty getting the [configure] script to execute properly.

I have a hack to fix it below, but I'm just not sure why __aarch64__ would not be configured properly. Could be that protobufs 3.20.x configure tool is the source of the failure.

See:

#define __aarch64__ <-------------------------------------added.

in wordsize.h file below.

But in the related link I was looking at the $CC compiler environment points at the aarch64-oe-linux compiler aarch64-oe-linux-gcc

Should it by default define __aarch64__. Is the problem with protobufs related to the autogen.sh ?(note this was run after the linux-dev/environment-setup script).

$ echo $CC
aarch64-oe-linux-gcc --sysroot=/home/mnidev/ti-processor-sdk-linux-rt-am62xx-evm-09.02.01.09/linux-devkit/sysroots/aarch64-oe-linux

github.com/.../protobuf.git

commit c18477fab24fee9a667965d9ea537e80f1648698 (HEAD -> 3.20.x, origin/3.10.)

But making this update I corrected the 32bit use errors.

ti-processor-sdk-linux-rt-am62xx-evm-09.02.01.09/linux-devkit/sysroots/aarch64-oe-linux/usr/include/bits

$ cat wordsize.h
/* Determine the wordsize from the preprocessor defines.

The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<www.gnu.org/.../>. */

#define __aarch64__ <-------------------------------------added.
#if defined (__aarch64__) && defined (__LP64__)
# define __WORDSIZE 64

3 months ago

0 Andreas Dannenberg 3 months ago

TI__Guru 57956 points

Hi RG,

can you please check out this post here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1344666/am4378-linux-devkit-compile-code-failed-for-ti-processor-sdk-documents-need-to-be-updated/5128591#5128591

Looks like you might be missing passing along the $CFLAGS variable, in addition to using $CC when compiling things.

Regards, Andreas

0 RG 3 months ago in reply to Andreas Dannenberg

Intellectual 350 points

Thanks for that I see some additional flags in the AM335 referred to.

But when working with AM62x: I don't see a size variable being added.

~/work/latest/protobuf (3.20.x)
$ echo $CFLAGS

~/work/latest/protobuf (3.20.x)
$ source ~/ti-processor-sdk-linux-rt-am62xx-evm-09.02.01.09/linux-devkit/environment-setup
~/work/latest/protobuf (3.20.x)
$ echo $CFLAGS
-mbranch-protection=standard --sysroot=/home/mnidev/ti-processor-sdk-linux-rt-am62xx-evm-09.02.01.09/linux-devkit/sysroots/aarch64-oe-linux

Thus, should I add flags: export CFLAGS="$CFAGS -D__aarch64__" ? Or should I modify environment-setup to add this flag?

0 RG 3 months ago in reply to RG

Intellectual 350 points

OK, adding the additional -D__aarch64__ flag corrected the issue - I think I'll update the environment-setup to add this automatically to prevent this manual step. Will TI make this change as well (assuming this is the correct path)?

0 Andreas Dannenberg 3 months ago in reply to RG

TI__Guru 57956 points

RG,

Let me look into this a bit closer to make sure we are fixing this in a proper way, but it'll take me a day or so before I can make time to get to this and set this up. Either way good to hear you can get it to build now.

Regards, Andreas

0 RG 3 months ago in reply to Andreas Dannenberg

Intellectual 350 points

Hi Andreas, I went back to reproduce and found that even after adding -D__aarch64__ to the CXXFLAGS and CFLAGS that the

configure script in:

~/work/latest/protobuf (3.20.x)
$ git remote -v
origin github.com/.../protobuf.git (fetch)
origin github.com/.../protobuf.git (push)

still fails. I see some other errors related to test code for ac_nonexistent.h (this file is supposed to be generated by the configure script so think there is something else related to protobufs or a compatibility with the environment generated by environment-setup script.

1636 conftest.cpp:40:10: fatal error: ac_nonexistent.h: No such file or directory 1637 40 | #include <ac_nonexistent.h>
1638 | ^~~~~~~~~~~~~~~~~~

0 Andreas Dannenberg 3 months ago in reply to RG

TI__Guru 57956 points

Hi RG,

thanks for the additional notes. I wasn't able to get to this today but should be able to do so tomorrow and will report back here.

Regards, Andreas

0 RG 3 months ago in reply to Andreas Dannenberg

Intellectual 350 points

Thanks I've re-added the __aarch64__ definition to wordsize.h in the target header files, as a work around since export CFLAGS="$CFLAGS -D__WORDSIZE=64 -D__aarch64__" Flags should work with protobufs but does not.

For now I'm working on gRPC cross compilation - Bazel is new, and the CMakeFiles for cross compilation of gRPC are also a challenge. Bazel makes it sound like you can just access some repo and pull down the cross compilation tools - but elsewhere others indicate this is a non-trivial effort. I'm wondering if Yocto Arago TI,

Reference: Here is a link PI related that talks about plugins for cross compilation: https://forums.raspberrypi.com/viewtopic.php?t=221482

0 Andreas Dannenberg 3 months ago in reply to RG

TI__Guru 57956 points

Hi RG,

I got a chance to look into this some more, a couple of quick comments below:

protobuf is part of Yocto (meta-oe/recipes-devtools/protobuf), in fact it is part of our SDK builds as well it looks like. Why are you not just using that, and instead try to cross-compile this outside Yocto "the hard way"? If you are doing that to get a newer version of this tool the first thing I'd do is check Yocto upstream branches for newer variants of the associated recipe, and either take that, or "borrow" from it, to make it work in the context of the current AM62x SDK v9.2 for example.
This being available in Yocto leads to the natural next step in looking at the recipe to see how it's being build, and see if there's anything we can learn from that: https://github.com/openembedded/meta-openembedded/tree/kirkstone/meta-oe/recipes-devtools/protobuf

As part of that you an see how the build recipe https://github.com/openembedded/meta-openembedded/blob/kirkstone/meta-oe/recipes-devtools/protobuf/protobuf_3.19.6.bb applies a bunch of patches located here https://github.com/openembedded/meta-openembedded/tree/kirkstone/meta-oe/recipes-devtools/protobuf/protobuf which is a pretty common thing usually done to make cross-compilation work.

Upon further examination, this patch here spikes out:

[PATCH] examples/Makefile: respect CXX,LDFLAGS variables, fix build
https://github.com/openembedded/meta-openembedded/blob/kirkstone/meta-oe/recipes-devtools/protobuf/protobuf/0001-examples-Makefile-respect-CXX-LDFLAGS-variables-fix-.patch

Remember how we earlier discussed about compiler flags, so this very much looks like related, as the patch fixes an issue in this regard. Please have a close look at this (but also the other patches and the build recipe, because everything there is done for a reason, that might apply to your scenario as well.

Regards, Andreas

0 RG 3 months ago in reply to Andreas Dannenberg

Intellectual 350 points

Hi Andreas,

ANS1) Nominal reason, I will need to check if this layer can go back to the earlier versions of protobuffs and grpc, for compatibility with existing fielded SW, trying to keep the existing applications consistent across two chips as much as possible and working with new build environments (going from STM to TI).

ANS2) Yes this seems like a good approach (need to factor in prior codebase/hardware). Have my work cut out for me, thanks for these points. I circle around and mark this fixed once I have both platforms working in a compatible manner.

I hope I'm at the low point of the Dunning-Kruger line!

0 RG 3 months ago in reply to RG

Intellectual 350 points

Hi Andreas,

Besides this issue with the eSDK system build:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1371283/processor-sdk-am57x-am623x-bitbake-tisdk-base-image--c-populate_sdk-completes-fine-but-bitbake-tisdk-base-image--c-populate_sdk_ext-fails/5239255?tisearch=e2e-sitesearch&keymatch=%20user%3A594119#5239255

I do see the grpc libraries now, but I would think I'd get the protoc compiler out of this as well if Yocto is supposed to build X86 style tools. Have for a while now, working on roads and bridges...

;

0 Andreas Dannenberg 3 months ago in reply to RG

TI__Guru 57956 points

RG said:
Besides this issue with the eSDK system build:

Ok thanks for the link; I just picked it up (it would have gotten assigned to me next anyways but it'd have taken a day for the process to work its way). Let's keep different threads on-topic, around a particular issue.

Regards, Andreas

Processors

Processors forum

PROCESSOR-SDK-AM62X: wordsize.h - when using