git on opkg "cortexa9-vfpv3" feed is too old for submodule feature

[Staab_Engineering]

Can a newer version (preferably current, v2.7.4) be built for ARM and hosted publicly so we can use "git submodule"? It's a critical feature to our repo structure.

[ScotSalmon]

"git submodule" has been around for a while (it's in 1.9.1 on my desktop Linux box), it's not the version that's the problem, it looks like that feature just isn't enabled in our build (not in the 2.0.1 in the 2015 feed or even in our latest internal feed with 2.3).

Can you explain a bit on how you're using git on the target? While I do occasionally use git on the target I wouldn't generally think it's where I need to do much git magic, so I'm curious what you use case is.

We can make a note to enable submodules if needed, I am not sure why it's not already but that is probably the default OpenEmbedded configuration for some nominally good reason.

[Staab_Engineering]

I'm trying to build a .so on the target for the ARM Cortex-A9 architecture. (We pretty much have to build all the tools we want to use on these ARM devices ourselves.) The source repo uses submodules to import features from open-source libraries.

Here's the specific issue I'm trying to address, in the interest of cross-pollination: https://github.com/featherweight/ftw-kernel/issues/2

[Staab_Engineering]

Can you point me to the latest public feeds? These are the ones that were preconfigured on my cRIO when I set it up using MAX:

src/gz url-0 http://download.ni.com/ni-linux-rt/feeds/2015sp1/arm/ipk
src/gz uri-all-0 http://download.ni.com/ni-linux-rt/feeds/2015sp1/arm/ipk/all
src/gz uri-cortexa9-vfpv3-0 http://download.ni.com/ni-linux-rt/feeds/2015sp1/arm/ipk/cortexa9-vfpv3
src/gz uri-xilinx_zynq-0 http://download.ni.com/ni-linux-rt/feeds/2015sp1/arm/ipk/xilinx_zynq

[Ken_S]

I can confirm that you are using the most recent public feeds.

[Josh Cartwright · Accepted solution]

OpenEmbedded packages git with the subcomponents which depend on 'perl' in their own package, called git-perltools.  'submodule' is one of such tools dependent on perl.  Can you try installing 'git-perltools' and seeing if git submodule works for you?

[Staab_Engineering]

Yep, that worked. Is that the right answer, installing git-perltools instead of git? Or does it still make sense to add a fuller feature set back into git?

[ScotSalmon]

Josh, that works (with 2015 feeds). Edit: and I'd say that's the "right" answer; "fixing" git to pull in Perl unconditionally seems not ideal for embedded systems. I marked his post accordingly.

Staab_Engineering wrote:

I'm trying to build a .so on the target for the ARM Cortex-A9 architecture. (We pretty much have to build all the tools we want to use on these ARM devices ourselves.) The source repo uses submodules to import features from open-source libraries.

Here's the specific issue I'm trying to address, in the interest of cross-pollination: https://github.com/featherweight/ftw-kernel/issues/2

While this particular issue seems solvable, doing any kind of heavy lifting build-wise on the 906x is going to hit others. Any chance you can cross-compile from desktop (Windows or Linux)? We make that toolchain available with Eclipse on Windows, and if we don't make it available for Linux already we probably can.

[Staab_Engineering]

Everyone on my team knows some shell scripting, git, and opkg/ipkg/yum. We can all pull another dev's repo, run configure and make, and watch it work. We aren't all C devs, though...cross-compiling is a specific skill that we'd have to hire onto the team. I, for example, would be completely lost trying to compile C code on my own.

I'd like to see NI's opkg feeds contain up-to-date versions of all packages for every architecture, but I know that's now how you're set up to operate as a public feed service. That's why we so often have to pull source and try to build on ARM ourselves...sometimes this includes the tools used to build the actual binaries we want to consume.

[ScotSalmon]

To be honest the cross compile experience need not be any harder than the local compile experience, and honestly possibly easier since you don't have to deal with headaches like the limited stack size, low disk/memory, disabled swap, disabled overcommit, etc. settings that plague a lot of posters on this forum when doing local builds. I'm pretty sure doing on the target is the hard way except for the most trivial builds. If you have access to a Linux development machine (even a VM running on Windows, so everyone should be able to set that up pretty easily with VirtualBox and your_favorite_distro CD/USB image), the only trick is getting the actual tools. Then your Makefile just does all the same commands, just with those tools instead of the development machine's native tools. Normally people want to do this on Windows so we package that up already. I don't think we did for Linux.