|
Vaclav_ wrote: it looks as Linux (kernel) contains "module" to interact with bluetooth.
Correct. The linux kernel needs to know how to communicate with a bluetooth adapter much the same as it needs to know how to communicate to a USB port or a NIC, etc. Bluetooth is quite ubiquitous these days, so the bluetooth module has been folded into the mainline kernel for quite some time.
Vaclav_ wrote: That "module" is based on "bluez" and they call it "stack" which I do not get. Why "stack" - isn't stack related to memory usage?
"Stack" in this sense is similar to what's known as a solution stack. The LAMP stack (Linux, Apache, MySQL, PHP) is an example. In this case the bluetooth hardware driver and the user tools are the bluetooth management stack.
Vaclav_ wrote: Why would one care where is the "bluez" physically?
OS should take care of that.
As long as it all works, you don't need to worry about where various bits are, the distribution installation packages manage all that for you.
Vaclav_ wrote: Now "bluez" can be installed into "user space".
And used for what ?
The kernel module only provides the hardware protocols to the linux kernel. To be able to do anything useful, you need the user-space tools such as bluetoothctl or btattch. This is no different, really, than the kernel module for your NIC which supplies the hardware protocols for network access and user space tools like ifconfig, ping and ssh which provide user level control and access to the network.
Vaclav_ wrote: To develop (C++) app for Bluetooth another app - "libbluetooth-dev" - has to be installed and configured for applicable architecture.
"libblutooth-dev" is based on "bluez".
Does that makes sense?
libbluetooth-dev is not an app, its the extra things on top of the bluez package that allow you to develop software which will communicate with or via a bluetooth controller. Suppose you have a production system that needs bluetooth - then you would only deploy the bluez package there. Typically, production systems should not contain any development tools, as you don't want random people creating software, or stealing cycles, on production systems. Your development system, on the other hand, not only needs compilers (gcc, g++, rustc, etc), but also needs include-files, debug libraries, etc so you can develop your application. Those items are generally divided out into the -dev packages, to allow for development/production separation.
|
|
|
|
|
Thanks , I thing I am making progress.
|
|
|
|
|
It looks as I have jumped the gun , again.
This bluetooth "stack" / library named "bluez" is somehow included in OS.
I can get some info about bluetooth devices using "system" calls.
That does not mean it can be used coding in C++.
I need to start from scratch and build the "bluetooth" library
or "bluetoothd".
1. download the latest "Linux stack" bluez-5.18 (?) - done
I am not sure why "they" call it "stack" , but that is not important.
2. follow "readme" and configure "it" (stack?) - partially done
3. run "make" and here I am stuck because it fails....
... tomorrow...
I probably asked this before, but .. here it goes
I have installed "bluetooth" library
apt-get install bluez libbluetooth-dev
and still getting this linker error
C_SPI_LCD.o ./src/MODULES/MODULE_1602/C_SSP.o ./src/MODULES/MODULE_1602/C_gpio.o ./src/VNA_1022_BASE.o -lgomp -lbluetooth -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/5/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lbluetooth
makefile:80: recipe for target 'VNAR_19321' failed
collect2: error: ld returned 1 exit status
make: *** [VNAR_19321] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
The Cross G++ Linker has an option "-lbluetooth" but I only specify "bluetooth" , without the "-l"
I did try to locate bluetooth
jim@jim-desktop:~$ find -name "bluetooth"
find: ‘./.cache/dconf’: Permission denied
find: ‘./.dbus’: Permission denied
find: ‘./.config/configstore’: Permission denied
jim@jim-desktop:~$ sudo find -name "bluetooth"
[sudo] password for jim:
jim@jim-desktop:~$ sudo find -name "*bluetooth"
jim@jim-desktop:~$ sudo find -name "*bluetooth*"
./.local/share/icons/bluetooth-wizard.png
./.local/share/applications/bluetooth-wizard.desktop
./.cache/upstart/indicator-bluetooth.log.5.gz
./.cache/upstart/indicator-bluetooth.log.4.gz
./.cache/upstart/indicator-bluetooth.log.2.gz
./.cache/upstart/indicator-bluetooth.log.3.gz
./.cache/upstart/indicator-bluetooth.log.1.gz
./.cache/upstart/indicator-bluetooth.log.6.gz
./.cache/upstart/indicator-bluetooth.log.7.gz
jim@jim-desktop:~$
Here are my questions / comments :
1. apparently the IDE adds the
"-l" to link to library - find with me.
2. Do I have to specify directory using "-L" and how do I find it using Linux?
3. It looks as there are no conventions as far as naming the library - some sources quote "libbluetooth"
Thanks
modified 4-Mar-19 0:53am.
|
|
|
|
|
You do not appear to have a bluetooth library installed. It should have the name libbluetooth.so or libbluetooth.a. Check the log from your installation process to see where it is supposed to be installed.
|
|
|
|
|
Thanks
I'll take a look at the log.
I a hAve never done that so it will take a while.
|
|
|
|
|
Since you're cross compiling for arm, you'll need to install libbluetooth for arm - if your distribution provides that - otherwise you'll either have to compile libbluetooth for arm (which may include compiling supporting libraries, too), or do your builds on your arm device.
You may be able to copy the bluetooth libs from your arm device. They should be at /usr/lib/libbluetooth.so* or /usr/lib64/libbluetooth.so*, but I don't know where they would copy to on your compilation system - probably somewhere under usr/lib/gcc-cross/arm-linux-gnueabihf/ - there's probably a lib or lib64 directory under there containing .so and/or .a files.
|
|
|
|
|
|
Also a note about find: find -name "bluetooth" only searches the current directory for a file or directory that matches the name "bluetooth" excactly. Similarly, using -name "bluetooth*" finds files and directories that start with "bluetooth". What you want to do is probably find / -type f -name "bluetooth" That will search the entire filesystem for files that contain the string "bluetooth". Of course, this also searches /proc, /sys /dev, etc that probably aren't of interest, so perhaps adding the flag -xdev, which keeps find to the current filesystem might be in order, too.
|
|
|
|
|
Thanks.
I was aware that I was getting only current directory finds.
I did modify the CL , but now I am getting only directories.
jim@jim-desktop:~$ sudo find / -type f -name "bluetooth" -xdev
[sudo] password for jim:
find: warning: you have specified the -xdev option after a non-option argument -type, but options are not positional (-xdev affects tests specified before it as well as those specified after it). Please specify options before other arguments.
/etc/init.d/bluetooth
/usr/local/lib/cups/backend/bluetooth
/usr/bin/bluetooth
/usr/lib/cups/backend/bluetooth
jim@jim-desktop:~$ sudo find / -type f -name -xdev "bluetooth"
find: paths must precede expression: bluetooth
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec|time] [path...] [expression]
jim@jim-desktop:~$ sudo find / -xdev -type f -name "bluetooth"
/etc/init.d/bluetooth
/usr/local/lib/cups/backend/bluetooth
/usr/bin/bluetooth
/usr/lib/cups/backend/bluetooth
jim@jim-desktop:~$
|
|
|
|
|
I think I need to link , using "_L" option to highlighted file and its directory.
jim@jim-desktop:~$ sudo find / -xdev -type f -name "libbluetooth*"
/var/lib/dpkg/info/libbluetooth3:amd64.md5sums
/var/lib/dpkg/info/libbluetooth3-dbg.list
/var/lib/dpkg/info/libbluetooth-dev.md5sums
/var/lib/dpkg/info/libbluetooth3:i386.shlibs
/var/lib/dpkg/info/libbluetooth3:amd64.list
/var/lib/dpkg/info/libbluetooth3:i386.symbols
/var/lib/dpkg/info/libbluetooth3-dbg.md5sums
/var/lib/dpkg/info/libbluetooth3:i386.md5sums
/var/lib/dpkg/info/libbluetooth3:amd64.triggers
/var/lib/dpkg/info/libbluetooth-dev.list
/var/lib/dpkg/info/libbluetooth3:amd64.symbols
/var/lib/dpkg/info/libbluetooth3:i386.triggers
/var/lib/dpkg/info/libbluetooth3:i386.list
/var/lib/dpkg/info/libbluetooth3:amd64.shlibs
/usr/lib/i386-linux-gnu/libbluetooth.so.3.18.10
/usr/lib/x86_64-linux-gnu/libbluetooth.a
/usr/lib/x86_64-linux-gnu/unity-control-center-1/panels/libbluetooth.so
/usr/lib/x86_64-linux-gnu/libbluetooth.so.3.18.10
jim@jim-desktop:~$
Addendum
Looks better , but now cannot link to "gomp" - lining to wrong "_L" ??
MODULES/MODULE_1602/C_1602.o ./src/MODULES/MODULE_1602/C_LCD2_CPP.o ./src/MODULES/MODULE_1602/C_SPI.o ./src/MODULES/MODULE_1602/C_SPI_LCD.o ./src/MODULES/MODULE_1602/C_SSP.o ./src/MODULES/MODULE_1602/C_gpio.o ./src/VNA_1022_BASE.o -lgomp -llibbluetooth -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-cross/arm-linux-gnueabihf/5/crtend.o /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/x86_64-linux-gnu/libgomp.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make: *** [VNAR_19321] Error 1
makefile:80: recipe for target 'VNAR_19321' failed
"make all" terminated with exit code 2. Build might be incomplete.
modified 3-Mar-19 13:34pm.
|
|
|
|
|
Nope.
That's an X86_64 binary, so it won't link with the ARM binary.
Additionally, if you'd bothered to even look at an OpenMP tutorial, as I suggested elsewhere, you would have realized that my suggestion to use -lgomp when compiling OpenMP source was wrong. The correct thing to do is to use -fopenmp, which enables #pragma omp ... processing. Whether cross compilation permits OpenMP or not, is unknown to me. If not, you're going to have to find another way to approach this.
|
|
|
|
|
Getting of the subject with sarcasm (... if you'd bothered to even look...)is not the way I am used to communicate here.
I really do not care about OpenMP (for now) , but as you can see fopenmp is also missing the "-L" .
Looks as the crosscompiler is smarter then expected and "skips" the wrong library anyway.
gnueabihf/5/../../../../arm-linux-gnueabihf/lib/../lib/crtn.o
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lfopenmp
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -llibbluetooth
makefile:80: recipe for target 'VNAR_19321' failed
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when searching for -lm
collect2: error: ld returned 1 exit status
make: *** [VNAR_19321] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
What is bothersome - the crosssompilier "runs" on "86" but the app will run on arm.
But I'll try to get bluez library for arm next.
|
|
|
|
|
No. Its not -lfopenmp, it is -fopenmp.
Given this hello.cpp:
#include <iostream>
int main()
{
std::cout << "hello world\n";
return 0;
}
then g++ -fopenmp hello.cpp -o hello produces an executable. We can use ldd to check the libraries linked in and we can see:
ldd hello
linux-vdso.so.1 (0x00007ffed35fb000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc385128000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc384fa0000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fc384f68000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc384f48000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc384f20000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc384d58000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc3852e8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc384d50000)
So using -fopenmp adds in libgomp (and turns on other OpenMP processing for you, too).
I'm wondering if you've produced any cross-compiled executables, yet. I'm using Fedora29, which doesn't seem to provide libstdc++ or any of the c++ include files for cross compiling arm. You're apparently using a non red-hat derived system, so your mileage will definitely vary, or you may already have resolved the cross-compilation issues, in which case, kudos!
|
|
|
|
|
Vaclav_ wrote: /usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -llibbluetooth
Because the option should be -lbluetooth the lib prefix is always assumed by the linker.
|
|
|
|
|
I am using Eclipse IDE and learned long time ago to "add" just name ( bluetooth) in "-l" option.
Eclipse is crazy - the file name is actually bluetooth.a , but the linker is optioned as "-lbluetooth". I could post the linker verbose output , but it is little too long.
My present problem is locating the "library" directory.
I did not install it properly and I am basically starting over.
|
|
|
|
|
Looking at the ld man page, I think you need a different form of the -l option. Try -l:bluetooth.a - note the colon and the .a suffix. When you just use -lbluetooth then the linker will search for a file called libbluetooth.a. I am not sure how you set these options in eclipse (a long time since I used it) but there is probably somewhere in the project settings.
As to the library directory, it should not be too difficult with a find command.
|
|
|
|
|
Looks like you learn something new every day (unless you're careful  ). I did not know about the -l:<filename> option for ld. In the past, when I needed to link to static (.a) libs I'd use gcc flags -Wl,-Bstatic -l<lib> -l<lib> ... -Wl,-Bdynamic. The -l:<lib> is nicer, I think. Note that if you omit the trailing -Wl,-Bdyanmic in my solution, then any static system libs (e.g. libc, libstdc++, etc) get linked statically, too, which may not be what you want.
I just tried this and can confirm it works, but you need to use the full filename i.e. -l:libxxxx.a e.g.
$ ls /usr/lib64/lib*.a
/usr/lib64/libc_nonshared.a /usr/lib64/libldc-jit-rt.a /usr/lib64/libmvec_nonshared.a
/usr/lib64/libg.a /usr/lib64/libmcheck.a /usr/lib64/libpthread_nonshared.a
$ g++ hello.cpp -l:mcheck.a -o hello
/usr/bin/ld: cannot find -l:mcheck.a
collect2: error: ld returned 1 exit status
$ g++ hello.cpp -l:libmcheck.a -o hello
$ . That means if your lib actually is $PATH_TO_LIBS/bluetooth.a then -l:bluetooth.a is correct.
|
|
|
|
|
$ g++ hello.cpp -l:mcheck.a -o hello
/usr/bin/ld: cannot find -l:mcheck.a
collect2: error: ld returned 1 exit status
$ g++ hello.cpp -l:libmcheck.a -o hello
Now why are you using the -l: version for a normally named library? For files named libxxx.a all you need is -lxxx, as I explained in my previous post (and in the man page). The only time you need the colon version is if the name does not begin with the lib prefix.
|
|
|
|
|
Richard MacCutchan wrote: The only time you need the colon version is if the name does not begin with the lib prefix.
Or if you want to link to the static version of a library, but not use -static for the whole executable.
It was not clear to me from your post that -l:xxxx.a was looking for a file $SOMEPATH/xxxx.a, since normally a library shared or otherwise would be libxxxx.a. I'm reasonably sure the bluetooth lib the OP is looking for would be libbluetooth.a, since it is part of the bluez package.
|
|
|
|
|
k5054 wrote: It was not clear to me from your post
Which is why I specifically mentioned the ld man page, where it is explained.
k5054 wrote: I'm reasonably sure the bluetooth lib the OP is looking for would be libbluetooth.a, since it is part of the bluez package.
According to Re: Linking to library - Linux Programming Discussion Boards[^] OP specifies the file does not have the lib prefix.
|
|
|
|
|
OK, I am doing something stupid trying to get # of CPU's in Raspberry Pi.
This returns "syntax error : end of file unexpected " and # of CPU's 512
#include <omp.h>
int iCPU = system ("omp_get_num_procs()");
cout << "# of CPU's " << dec << +iCPU << endl;
exit(1);
Any second opinions ( leading to solution ) are welcome and appreciated.
Cheers
Vaclav
SOLVED
Was missing link to gomp library
modified 8-Feb-19 15:54pm.
|
|
|
|
|
See the man page for system() - its essentially a wrapper around execl() and vfork(). Unless you can execute "omp_get_num_procs()" from the command line, what you have won't work.
Why would you think you need a call to system() in this case?
|
|
|
|
|
This is response from CL on my PC
jim@jim-desktop $ omp_get_num_procs()
>
and this is coming from RPi
pi@pi $ jim@jim-desktop $ omp_get_num_procs()
-bash: syntax error near unexpected token `('
pi@pi $ >
-bash: syntax error near unexpected token `newline'
pi@pi $ sudo omp_get_num_procs()
The purpose / reason was posted in OP.
-bash: syntax error near unexpected token `('
pi@pi $ sudo omp_get_num_procs
sudo: omp_get_num_procs: command not found
pi@pi $
I'll check the man.
|
|
|
|
|
Let me try this another way.
In your last question to this discussion board (from "ls" to C++ buffer?) you asked about capturing the output from system() into your C++ program. I take it from that, that you know what the system() call does - i.e. calls a system command like ls, or ps or grep, etc. So now you seem to be wanting to call a function provided in the omp.h header via the system() call. That makes no sense to me. The only reason I could think you might want to do that was if you were trying to execute the function as a different user - in which case that is not the way to go about that. So my question stands - why are you trying to wrap what appears to be a normal, ordinary C function call inside a call to system()?
|
|
|
|
|
You do not need parentheses on command/program calls in the system. Change your code to:
int iCPU = system ("omp_get_num_procs");
Although I do not expect that a call to system will return the output from the command. Also I suspect you also need to wrap that code in a int main(){} block in order to compile it correctly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
