Linking Armadillo and OpenBlas on Windows 10 - g++

Beginner here so apologies if the question is basic or poorly organized.
I am trying to link Armadillo 10.3.0 to OpenBlas 0.3.13 on Windows 10 using the pre-compiled OpenBlas here and am running into undefined reference issues.
When I compile my C++ using g++ my_script.cpp -o my_script -I "C:/.../armadillo-10.3.0/include" -DARMA_DONT_USE_WRAPPER -L "C:/.../armadillo-10.3.0/examples/lib_win64/libopenblas.dll" -I "C:/.../boost_1_75_0", it works perfectly when my_script.cpp only includes basic Arma operations.
However, if I add certain Arma operations (e.g., chol, mvnrnd) I run into several undefined reference to `xxx' issues (see example below) when I try to compile:
C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\XXX\AppData\Local\Temp\12\cc0AVY6p.o:my_script.cpp:
(.text$_ZN4arma6lapack5syevdIdEEvPcS2_PiPT_S3_S5_S5_S3_S3_S3_S3_[_ZN4arma6lapack5syevdIdEEvPcS2_PiPT_S3_S
5_S5_S3_S3_S3_S3_]+0x83): undefined reference to `dsyevd'
I have tried:
Playing around with armadillo_bits/config.hpp to adjust flags per here
Checking arma::arma_config to see if .blas and .lapack are true / enabled after compiling the version of my_script.cpp without the troublesome Arma operations (they are true/enabled)
If anyone has any thoughts on this would appreciate any guidance, thanks!

Related

Cmake error: could not find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND)

I'm trying to install a software called relion on a windows pc, but am running into some issues. I try to build relion with <cmake .. -G 'Visual Studio 16 2019'> to set my C compiler, and I am not able to find MPI
MPI, a standard, has several implementations. See this old but good answer covering the options you've got (MS-MPI or Intel-MPI )
https://stackoverflow.com/a/21165460/1024740

Building a kernel module on Centos 7 with a CMake file

Sorry for the length. I have tried to include as much information as possible.
A device I work with randomly fails to start at boot - this is a well known issue with the device and there are lots of posts on the web with no known solution except reboot.
So the task is to look in dmesg for a certain string that if present means the device has failed to start and the system needs rebooting. A simple call to system() with boot seems to do the job.
A unit test that proves this would be nice. The idea is to look for a non-existant uuid in the dmesg log to prove that it fails to find one and then to write a different uuid to the log and then search for that. Proving it works in both cases.
First thing was to hit up google: Find you can write to the kernel log with # echo '<4>Foo: Message' | sudo tee /dev/kmsg which works from terminal but the sudo may cause issue in the unit test.
The next thing I looked at was accessing it via code. The unit tests are written in C++ and the library is googletest.
Most posts talk about writing a Makefile and kbuild. I am working in a build system where we have cmake called from a shell script.
After several hours of searching and trying things, I decided to ask here.
I have installed
kernel.x86_64 3.10.0-1062.el7 #anaconda
kernel.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-devel.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-devel.x86_64 3.10.0-1160.24.1.el7 #updates
kernel-headers.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-tools.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-tools-libs.x86_64 3.10.0-1160.21.1.el7
uname -r gives 3.10.0-1160.21.1.el7.x86_64 which seems to suggest I have the kernel headers and devel files installed.
Doing a find /. -name module.h lists:
...
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/arch/x86/include/asm/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/asm-generic/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/linux/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/trace/events/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/uapi/linux/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/arch/x86/include/asm/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/asm-generic/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/trace/events/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/uapi/linux/module.h
...
It maybe that I am trying to link files in /3.10.0-1160.24.1.el7.x86_64/ when I should be linking to 3.10.0-1160.21.1.el7.x86_64/. Listing installed yum packages via sudo yum list | grep linux-d returns
libselinux-devel.x86_64 2.5-15.el7 #base
libhbalinux-devel.i686 1.0.17-2.el7 base
libhbalinux-devel.x86_64 1.0.17-2.el7 base
libselinux-devel.i686 2.5-15.el7 base
syslinux-devel.x86_64 4.05-15.el7 base
My CMakeFiles.txt looks like
project( X_test )
set( TEST_SOURCE
X_test.cpp
)
execute_process(COMMAND uname -r OUTPUT_VARIABLE uname_r OUTPUT_STRIP_TRAILING_WHITESPACE)
include_directories(/usr/src/kernels/${uname_r}/include)
link_directories(/lib/modules/${uname_r}/build)
add_library(source-lib STATIC source.c)
Anything else in there has been commented out to prevent confusion.
Without the lines include_directories or link_directories I get the error
#include <linux/module.h>
With those lines in I get the error:
In file included from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/kernel.h:6:0,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/cache.h:4,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/time.h:4,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/stat.h:18,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/module.h:10,
from /home/user/git/asdo/Services/DCO-3303/test/source.c:1:
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/linkage.h:7:25: fatal error: asm/linkage.h: No such file or directory
#include <asm/linkage.h>
The code I am compiling is the standard printk(KERN_INFO "Hello world\n"); which you can see here.
How do I go about compiling code that uses a kernel call through CMake?

Tensorflow Lite and edgetpu_compiler: Compiling for version 10 gives "Internal compiler error. Aborting!"

I am attempting to compile the code at this Coral example on Colab to run on runtime version 10, since I have a Coral USB Accelerator connected to a customized build for Raspberry Pi Zero W.
The command I'd like to get working is
edgetpu_compiler --min_runtime_version 10 [.TFLITE file]
It always ends with an internal error; unknown to me why that would be...? The error is:
Edge TPU Compiler version 2.1.302470888
Internal compiler error. Aborting!
To reproduce this, you should do the import, preparation, build, and first training steps. No need to fine-tune: results are the same.
I understand that certain operations are not available for lower runtimes, but I am at a loss at what exactly would need to change in the demo so as to compile it successfully.
Does anyone know what might be missing, or otherwise provide guidance?
just got a chance to check this out, looks like there is actually a bug preventing compilation at older runtime version...
This is fixed as I'm able to compile this model with -m 10 form the code base, it'll be fixed for you by next release. For now here is a work around (essentially checking out an older compiler version to compile the model):
$ git clone https://github.com/google-coral/edgetpu.git && cd edgetpu
$ git checkout 657d2b6
$ ./compiler/x86_64/edgetpu_compiler -s -m 10 /path/to/model
This should works, although with an older runtime, many ops weren't supported then so you may not see the performance increase that you would with the current runtime version!

ObjC ARC contraction (clang crash)

I always hesitate to add a brand new question to the killer forums here, but I haven't seen anything close to this bug.
Seems clang has crashed on my while compiling one of my .m files. If anyone has seen or knows of any solution for the below I'd be immensely obliged.
This error occurs when I build for armv6 in a release configuration using XCode 4.4.1
But does not occur when I build for armv6 in a debug configuration, or release for armv7, armv7s or i386.
The specific error is "ObjC ARC contraction":
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module '/Users/Me/Documents/ThisProject/iOS/..../ClassFoo.m'.
4. Running pass 'ObjC ARC contraction' on function '#"\01-[ClassFoo evalJS:]"'
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to http://developer.apple.com/bugreporter/ and include command line arguments and all diagnostic information.
In the ../Intermediaries/Project.build/armv6/ folder I see:
ClassFoo.dia
and I should see (like all of its surrounding files)
ClassFoo.d
ClassFoo.dia
ClassFoo.o
Here are the top 4 of the clang stack, in case someone recognizes something in it:
0 clang 0x00000001010536f2 main + 17107682
1 clang 0x0000000101053b79 main + 17108841
2 libsystem_c.dylib 0x00007fff93c428ea _sigtramp + 26
3 libsystem_c.dylib 0x00007fff93c7a54e tiny_malloc_from_free_list + 1078
edit: I also noticed when trying again recently that I'm getting complaints about the -fno-objc-arc flag -- perhaps the compiler sym-links are pointing at the wrong binaries?
Thanks in advance,
Miles
Thanks for all your interest, and I'm sorry to have to answer this question myself but no other solution I've tried has resulted in anything successful. I've done my best to document my adventure here as a how-to-guide to hopefully help a few others.
The short version:
Xcode 4.5+ does not support building to armv6 (iphone 3g).
With fresh installs of 4.5 & 4.4.1 I experienced various versions
of the original error.
The reason is two-fold:
xcspec files Xcode uses do not include entries for this architecture.
4 needed libclang_rt*.a files have had their armv6 slices stripped.
There is a solution! (see long version below)
The long version:
Amongst the many many frustrating attempts I made to sort this issue out, such as searching SO forums, searching apple dev forums, googling, endlessly fiddling with project settings, copying earlier SDKs into the Xcode.app packages, posting this question, filing a bug report with Apple, etc. ad infinitum <-- means, "and so in into infinity" each seemed to have either nothing pertinent to reveal or only a tiny tidbit of information.
The recipe for this solution finally took one frustrated and determined developer and the culmination of everything in one very long night.
So where's the how-to?
( Right here, bro )
There are about 12 steps, so don't forget the final ones below the images!
Disclaimer: This is my own solution and it works great for me, but if you're not sure about what's going on or what you're doing please be very careful and realize that I will assume no responsibility for any damages you may incurr by trying to follow these steps. That said, here you go!
If you don't already have a copy, download Xcode 4.4.1 from http://connect.apple.com
Extract /PATH_TO_YOUR_Xcode_4.4.1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk
Copy it to /PATH_TO_YOUR_Xcode_4.5.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/
Now you'll edit 4 Xcode .xcspec files in your Xcode 4.5:
Navigate here: /PATH_TO_YOUR_Xcode_4.5.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Specifications
Select these files:
iPhoneXcode4Options.xcspec
iPhoneOSArchitectures.xcspec
iPhoneCompilerOptions.xcspec
iPhoneClangOptions.xcspec
Right-click and select "Open with Xcode"
Repeat for Xcode 4.4.1, and stick the two windows side-by-side (just makes this easier).
You're going to add armv6 to several entries as below:
Here again:
And here:
Here you cut & paste an entry from Xcode 4.4.1 to Xcode 4.5:
Alright you completed that tediousness, yay! Save the edited files and close them all. Next you have to create new libclang_rt*.a files to handle compiling these arches. This step is more easily done in Terminal. Enter these commands:
Make sure the backups copy and there isn't some error in paths or typing!
cd /PATH_TO_YOUR_Xcode_4.4.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/4.2/lib/darwin
sudo mkdir armv6_extractions
lipo -extract armv6 -output armv6_extractions/libclang_rt.ios.armv6.a libclang_rt.ios.a
lipo -extract armv6 -output armv6_extractions/libclang_rt.profile_ios.armv6.a libclang_rt.profile_ios.a
lipo -extract armv6 -output armv6_extractions/libclang_rt.cc_kext.armv6.a libclang_rt.cc_kext.a
sudo cp -R armv6_extractions /PATH_TO_YOUR_Xcode_4.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/4.2/lib/darwin
cd /PATH_TO_YOUR_Xcode_4.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/4.2/lib/darwin
sudo mkdir originals
sudo cp libclang_rt.ios.a originals/
sudo cp libclang_rt.cc_kext_ios5.a originals/
sudo cp libclang_rt.profile_ios.a originals/
lipo -create -output libclang_rt.ios.a armv6_extractions/libclang_rt.ios.armv6.a originals/libclang_rt.ios.a
lipo -create -output libclang_rt.cc_kext_ios5.a armv6_extractions/libclang_rt.cc_kext.armv6.a originals/libclang_rt.cc_kext_ios5.a
lipo -create -output libclang_rt.profile_ios.a armv6_extractions/libclang_rt.cc_kext.armv6.a originals/libclang_rt.profile_ios.a
Restart Xcode 4.5
^...I wrote "11" here...why's it showing as "1"?
Open your project and edit your settings accordingly. I recommend that you create a separate configuration just for building to armv6, and lipo everything together when you're done.
Add armv6 to Valid Architectures
Add armv6 to Architectures
For your specific armv6 configuration, set Base SDK to iOS 5.x (whatever is now listed in the drop-down menu)
Set your deployment target as needed ( I have built as low as iOS4.1 so far, and I believe the iOS5.x sdk you installed in the beginning can deploy as low as 4.x )
Okay, I think that's all.
If anyone sees any edits that need to be made PLEASE do so, and I welcome any feedback that anyone has to give here.
If something goes wrong, fingers crossed you can always reinstall your Xcode and try again (or not).
Best of luck.
I have had this problem before.... did you initialize your .m more than once? or import it? the only time this issue has occurred for me is when I tried to initialize or import a .m file somewhere other than where its native environment was.
A compiler should not crash. If it does then the vendor needs to fix it. Unfortunately I don't think you will be able to get any useful response via a Radar from Apple because they have moved on: there is a newer version of Clang in Xcode 4.5 and they don't support armv6 any more.
Having said that you should open a Technical Support Incident, because likely they can provide you with a workaround.
The error message indicates an internal error in the compiler while processing the function #"\01-[ClassFoo evalJS:]". You might be able to get around the error by rearranging the code in that function and/or adding volatile to local variables in that function.

Using bitbake to build a custom gumstix kernel

I've a gumstix Overo which I am configuring to work with a e-CAM camera. The documentation provided by camera manufacture asks me to patch a 2.6.34 kernel and compile in Video For Linux support. When I look at gumstix user documentation they say I should execute:
bitbake -c menuconfig virtual/linux
However when I run this command I get
bacon:~/proj/overo-oe$ bitbake -c menuconfig virtual/linux
NOTE: Handling BitBake files: \ (7100/7100) [100 %]
NOTE: Parsing finished. 6382 cached, 413 parsed, 305 skipped, 2 masked.
ERROR: Nothing PROVIDES 'virtual/linux'
I'm not altogether sure about how I provide virtual/linux. Any ideas about how to fix this error?
This might be a case of out-of-date documentation. In any case, my current work around is to name the kernel explicitly: bitbake -c menuconfig linux-omap3-2.6.34
I can help with a step-by-step procedure to bitbake 3.0 kernel.
If that may be helpful for you. Using a WMware Ubuntu ...
I would stay away from convoluted build systems as bitbake. Every one seems to be inventing one... making the 'tool' to get more of your time then the thing you want to do with the tool. All of them are the same. Linus would quote on those guys:
Just don't do it...!