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.
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.
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.
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.
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.
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
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....
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"
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.
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.
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.
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"
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.
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!
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.
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.
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.
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()?