Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 03 12:12
    bjornstromberg commented #68
  • Jul 03 11:30
    bjornstromberg opened #68
  • Jul 02 14:39
    kekxv opened #596
  • Jun 29 10:32
    Bycob edited #595
  • Jun 29 10:21
    Bycob opened #595
  • Jun 28 13:46
    ankitgit edited #594
  • Jun 28 13:45
    ankitgit opened #594
  • Jun 25 19:34
    falko-strenzke closed #593
  • Jun 25 19:34
    falko-strenzke commented #593
  • Jun 23 14:22
    falko-strenzke commented #593
  • Jun 20 14:04
    hw-dwalter opened #67
  • Jun 20 13:37
    hw-dwalter commented #593
  • Jun 20 13:34
    hw-dwalter commented #593
  • Jun 20 10:34
    Alberto-Izquierdo commented #531
  • Jun 16 18:18
    falko-strenzke commented #433
  • Jun 16 12:59
    falko-strenzke opened #593
  • Jun 16 10:08
    Alberto-Izquierdo commented #531
  • Jun 16 08:44
    Alberto-Izquierdo commented #531
  • Jun 16 08:04
    wjr20138216 opened #592
  • Jun 15 12:23
    mdumont-arcom opened #591
mmn
@mmn:matrix.org
[m]
Will tell you the arch for sure.
AlexandreHURDYK
@AlexandreHURDYK
Linux LX379-agurdyk 5.4.0-90-generic #101~18.04.1-Ubuntu SMP Fri Oct 22 09:25:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
mmn
@mmn:matrix.org
[m]
OK, so you are trying to cross-compile it from an x86_64 machine.
AlexandreHURDYK
@AlexandreHURDYK
Yeah. Target machine is 32 bits (so technically x86 right ?).
mmn
@mmn:matrix.org
[m]
No.
There is a ton of 32bit architectures.
x86 being only one of them, armhf (your target) another.
AlexandreHURDYK
@AlexandreHURDYK
Ouch
To things weren't even really compatible to begin with.
mmn
@mmn:matrix.org
[m]
So, if you have access to an old raspberry pi, that would be the easiest way to build it for your target (armhf) architecture.
Another option is to use qemu virtualisation.
AlexandreHURDYK
@AlexandreHURDYK
I don't think we have something like that, but maybe we can use the piece of hardware we're using that hosts our homemade OS in the same way. I'll try to ask a coworker.
If all else fails, it's qemu time to emulate a raspberry PI, right ?
mmn
@mmn:matrix.org
[m]
What are the ram/storage capacities of your target hw?
AlexandreHURDYK
@AlexandreHURDYK
No idea. Perhaps I can check with a command ?
mmn
@mmn:matrix.org
[m]
You don't know the device you are developing for?
AlexandreHURDYK
@AlexandreHURDYK
It's literaly a circuit board with an home made OS inside. Jobplace gave this to me monday without much precisions and told me to make my program work on that circuit board.
So I'm afraid that I lack a lot of critical information about what that improvised computer can do.
:/
I can however try to ask a coworker in a few minutes.
mmn
@mmn:matrix.org
[m]
Okay, but then that's maybe not a question for this forum. If you are going to cross-compile for an embedded device, that's quite a specialised discipline... I can try to compile oat++ on my lime2 this afternoon (which is 32 bit arm), but that one runs a full debian distro.
AlexandreHURDYK
@AlexandreHURDYK
All I should need is the two static library files so maybe just doing that on that debian distribution could work.
mmn
@mmn:matrix.org
[m]
What do you get after running
file ../ext/oatpp-1.3.0/lib/cortexa9hf_neon_Release/liboatpp.a
(replace the path with your actual path, of course)
AlexandreHURDYK
@AlexandreHURDYK
Linker says it ignores them outright because they're not compatible, then says "cannot find -l:liboatpp.a".
mmn
@mmn:matrix.org
[m]
But what does file say?
AlexandreHURDYK
@AlexandreHURDYK
Uuuuh hold on.
I got confused and didn't realize "file" was a command.
liboatpp.a: current ar archive
Mmmmh that doesn't seem to say a lot.
mmn
@mmn:matrix.org
[m]
Okay, it indeed doesn't.
What about objdump -a path/to/liboatpp.a?
AlexandreHURDYK
@AlexandreHURDYK
This one dumps a lot of stuff. Are you looking for a line in particular ?
mmn
@mmn:matrix.org
[m]
More like any one record.
I get for example
Pattern.cpp.o: tiedostomuoto elf64-x86-64
rw-r--r-- 0/0 417832 Jan 1 02:00 1970 Pattern.cpp.o
AlexandreHURDYK
@AlexandreHURDYK
Let's pick one .o entry at random then
Processor.cpp.o: format de fichier elf32-i386
rw-r--r-- 0/0 190588 Jan 1 01:00 1970 Processor.cpp.o
mmn
@mmn:matrix.org
[m]
yeah
AlexandreHURDYK
@AlexandreHURDYK
format de fichier means "file format"
mmn
@mmn:matrix.org
[m]
I know.
Je comprends.
This is the important thing: elf32-i386
So you didn't cross-compile it for (32bit) arm, you just built it for 32bit x86 architecture.
AlexandreHURDYK
@AlexandreHURDYK
Darn. So it was bad all along.
Ok so at least we know why it doesn't work now.
mmn
@mmn:matrix.org
[m]
Yeah. So you have to somehow convince cmake to use your cross-compiling (for armhf) toolchain instead of your native (x86_64) one. Maybe the line source /opt/phytec-yogurt/BSP-Yocto-i.MX6-PD18.1.1/environment-setup-cortexa9hf-neon-phytec-linux-gnueabi should have done something like that, but apparently it didn't.
https://embeddeduse.com/2017/06/03/cmake-cross-compilation-based-on-yocto-sdk/ could help, idk.
Or maybe this https://stackoverflow.com/questions/41964891/yocto-sdk-with-cmake-toolchain-file
AlexandreHURDYK
@AlexandreHURDYK
Alright. At least now I know what went wrong. Thanks for the troubleshooting. I'll try these links out. :)
Fabrice Aeschbacher
@aeschbacher
@AlexandreHURDYK BTW if you're using Yocto (and not an external toolchain) oat++ builds just fine with 
# PN, SRC_URI et all as usual , then
inherit cmake

FILES_${PN}-staticdev += "${libdir}/*"

EXTRA_OECMAKE = "\
  -DCMAKE_BUILD_TYPE=Release \
  -DOATPP_BUILD_TESTS=OFF \
mmn
@mmn:matrix.org
[m]
Hi, I'm trying to somehow get into Oat++, but I am honestly quite struggling with the documentation. Oat++ uses macros a lot for a C++ library (maybe even more than what I am used to from C where one does not have templates etc.), and at least to me function of many of them is far from obvious without looking into the code.