|
Sorry ,but how does that answer my question about exiting after perror?
I do not see anything indicating it should exit.
|
|
|
|
|
Take another look, it tells you exactly what perror does in the description: Quote: The perror() function produces a message on standard error describing
the last error encountered during a call to a system or library
function.
|
|
|
|
|
After reading this resource www.bluez.org I am trying to figure out how or if it is possible to control implementation of “libbluetooth-dev” on selected architecture.
The “bluez” README suggest some options, but after downloading and scanning thru “configure” file itself I am not sure where to find “configure” dependency on underlying architecture.
The “configure” is several hundred pages long and to be honest - I am little lost where to start.
I also checked this http://www.linuxfromscratch.org/blfs/view/8.3/general/bluez.html but it did not help me.
Any suggestion to accomplish the task will be appreciated.
PS
At present I hesitate to download the “configure” file here – it is too big.
Cheers
Vaclav
Addendum
I think this will answer my question
Cross Compiling BlueZ Bluetooth tools for ARM - BeyondLogic[^]
wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.18.tar.xz
tar -xJf bluez-5.18.tar.xz
cd bluez-5.18
./configure --host=arm-linux-gnueabi --prefix= PKG_CONFIG_PATH=/usr/arm-linux-gnueabi/lib/pkgconfig --disable-systemd --disable-udev --disable-cups --disable-obex --enable-library
make
make install DESTDIR=/usr/arm-linux-gnueabi
make install DESTDIR=/home/export/rootfs
modified 6-Mar-19 18:17pm.
|
|
|
|
|
|
The proverbial "chicken or egg".
Knowing the term (host) makes the search child's play.
Thanks.
|
|
|
|
|
Hi,
A bit of background:
I recently worked out how to cross compile/build/flash ESP32 projects ( C/C++ ) from my windows 10 machine, from a virtual Ubuntu machine and from a colleague's Apple OSX ( sierra ) machine.
Once I had it up and running on all those platforms from their respective Command line shells ( Using the mingw32 shell on the Windows machine ) I made a set of JSON configuration files for VSCODE that works equally well on all mentioned platforms so that I can use VSCODE to get IDE like functionality.
As I have a Raspberry PI3B and some time for the time being I would like to repeat the same experiment for the raspberry PI. If I can find a way to compile/build/flash C/C++ projects from the mingw command line for the raspberry PI I am sure I could set up VSCODE to provide a sort of IDE functionality for any PI project.
I already have the required "arm-linux-gnueabihf" toolchain but in spite of there being tons of info out there a simple example for say a "hello world" applicaton which uses "make" and a "makefile" is near impossible to find, at least I have not found it.
Any help/pointer much appreciated and if I do succeed I will post how I pulled it off.
|
|
|
|
|
I have been doing same - crosscompiling C++ "between" X86 (Ubuntu) and RPi 3B ( ARM).
I am using Eclipse IDE with Target Communication Framework - TCF.
Not the best setup.
Eclipse C++ IDE is being "updated" at breakneck speed and nobody does QA.
TCF is an orphant with no real relations with Eclipse "foundation".
It has been time consuming process to make Eclipse and TCF to play together.
And to answer your request and be brutally honest - I have not found a single resources explaining how crosscompiling works.
My latest "task" is to crosscomplie ( still X86 ) with a library build for ARM. See this forum.
Talking about a mess.
Cheers
Vaclav
|
|
|
|
|
I the mean time I have cobbled some things together and I am able to run a make command which appears to produce an output but I am not sure yet it runs on a raspberry PI.
Anyway: I can run "make" which uses this makefile:
TARGET_EXEC ?= a.out
BUILD_DIR ?= ./build
SRC_DIRS ?= ./main
SYSROOT = /c/msys32/home/RPI/SysGCC/arm-linux-gnueabihf/sysroot
CROSS_COMPILE = /C/msys32/home/RPI/SysGCC/bin/arm-linux-gnueabihf
CXX = $(CROSS_COMPILE)-g++ --sysroot $(SYSROOT)
CC = $(CROSS_COMPILE)-gcc --sysroot $(SYSROOT)
AS = $(CROSS_COMPILE)-as
AR = $(CROSS_COMPILE)-ar
NM = $(CROSS_COMPILE)-nm
LD = $(CROSS_COMPILE)-ld
SRCS := $(shell find $(SRC_DIRS) -name *.cpp -or -name *.c -or -name *.s)
OBJS := $(SRCS:%=$(BUILD_DIR)/%.o)
DEPS := $(OBJS:.o=.d)
INC_DIRS := $(shell find $(SRC_DIRS) -type d)
INC_FLAGS := $(addprefix -I,$(INC_DIRS))
CPPFLAGS ?= $(INC_FLAGS) -MMD -MP
$(BUILD_DIR)/$(TARGET_EXEC): $(OBJS)
$(CC) $(OBJS) -o $@ $(LDFLAGS)
# assembly
$(BUILD_DIR)/%.s.o: %.s
$(MKDIR_P) $(dir $@)
$(AS) $(ASFLAGS) -c $< -o $@
# c source
$(BUILD_DIR)/%.c.o: %.c
$(MKDIR_P) $(dir $@)
$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@
# c++ source
$(BUILD_DIR)/%.cpp.o: %.cpp
$(MKDIR_P) $(dir $@)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -o $@
.PHONY: clean
clean:
$(RM) -r $(BUILD_DIR)
-include $(DEPS)
MKDIR_P ?= mkdir -p
Most of it comes from here:
A Super-Simple Makefile for Medium-Sized C/C++ Projects[^]
It has some merits as it automatically finds and builds any "c" files located in the "main" directory as specified and any "c" files in any subdirectories.
The bit with the SYSROOT comes from here:
http://www.lilug.org/w/images/e/e6/T_Rothamel_Presentation_CrossCompiling_8_Jul_2014.pdf[^]
It appears to build my hello_world_main.c in directory main, my test.c file in directory main/test and produces the specified a.out file in the Build directory. During the process it calls the necessary arm-linux-gnueabihf-gcc cross development tool so I guess it might just be an operational executable for the Raspberry PI. I will know more tomorrow.
|
|
|
|
|
Thanks for the post.
I must admit that I got so spoiled by Eclipse IDE building the "make" I am really ignorant how to do it manually. Someday it will bite me.
I did not quite get this - is your compiler runnig on Linux or Windows?
|
|
|
|
|
Hi,
Until now I used to use Eclipse a lot as well but having installed the ESP32 toolkit with Eclipse I did get to know a bit more about it as you have to get it up and running via command line first before you can use integrate it with Eclipse. Having done that you don't need to know much about makefiles etc... but I was curious how it all works so I caught on to some of it.
As mentioned It enabled me to combine VSCODE with the build tools instead of Eclipse which I have been using for almost a year or so for ESP32 development.
The main advantage of that is that VSCODE works a lot faster and if you play it right with some ENVIRONMENT VARIABLES you can use exactly the same JSON configuration files for VSCODE on all platforms ( Windows, Linux and MAC OS ) to build the ESP32 application(s). No need to change a single letter in them.
As to your question: I am building the Raspberry PI application on a Windows 10 machine but I am using MSYS2 which creates a MinGW32/64 shell on a windows machine so that you can run Linux style build tools ( like GCC or a GCC cross compiler ) on your Windows machine.
For now I am simply using the command line in the MinGW32 shell to run the make command.
Tomorrow I will be testing if it actually runs on the Raspberry PI and try to remote debug it using gdbserver on the PI and a gdb client on the Mingw32 side. If that works using VSCODE to provide an IDE like system to build/debug it all should be a piece of cake as VSCODE provides support for all of that.
If it all works I will publish an article on how to do it all, then there will be an overview on how to cross compile from a Windows/Linux/OS-X host on a Raspberry PI target that keeps the KISS principle in mind.
|
|
|
|
|
First confirmation: it actually works on the Pi so the cross compilation/build works, now I can try to get the GDB stuff working.
|
|
|
|
|
Great.
I am still trying to figure out the relations between "bluez" and "libbluetooth.x".
My app will eventually pass data from RPi to PC - for better display.
I am tempted to shelve the RPi part for now and do the PC which would be "local" - not crosscomplied.
I did try "configure " (bluez) with -host=..ARM... but got errors I need to interpret to continue.
|
|
|
|
|
Well, it did take most of the day but In the end I got the GDB stuff up and running: gdbserver on the PI and arm-linux-gnueabihf-gdb.exe on the windows machine. It actually uses breakpoints, single stepping etc... as you would expect to find in, for example, Visual Studio.
On Monday I need to do some cleaning up, introduce a few remaining refinements and make some documentation but all in all it works pretty well. I think I will turn it into an article to post here.
|
|
|
|
|
Just FYI - for community benefit - no reply necessary .
1. Retrieve the current "bluez" source from www.bluez.org into desired folder and extract.
2, Modify "configure" file / command options as required (--enable-library etc. )
3. Run "configure"
4. Run "checkinstall" with desired options - (-A to select architecture ) as required
5. Enjoy the ride and you are DONE!
6. Link gcc ("-l") to "bluetooth" library and to library path ("-L") as provided by "configure" output.
This post is yet another request for assistance implementing bluetooth using "bluez".
It is sort of duplicate and vent about my other post which went down on the wrong track.
I am not asking for C++ code, I am asking for assistance to help me understand the overall concept of developing bluethooth application, and also include some details I am having trouble with.
I understand how bluetooth works, no need of any help there.
I have been successfully crosscompiling my Linux app using Eclipse IDE.
No need for any help there neither.
I understand "bluez" is included in Linux kernel and when I try to re "install " it again I get this:
jim@jim-desktop:~$ sudo apt-get install bluez
[sudo] password for jim:
Reading package lists... Done
Building dependency tree
Reading state information... Done
bluez is already the newest version (5.37-0ubuntu5.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
jim@jim-desktop:~$ ssh pi@10.0.1.76
pi@10.0.1.76's password:
Linux pi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Mar 4 05:37:40 2019 from 10.0.1.45
pi@pi:~ $ sudo apt-get install bluez
Reading package lists... Done
Building dependency tree
Reading state information... Done
bluez is already the newest version (5.43-2+rpt2+deb9u2).
The following package was automatically installed and is no longer required:
realpath
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
pi@pi:~ $
I can run bluetooth system calls , in both OS , to verify bluez too.
Am I correct to say I have "precompiled " bluez application on both systems?
Please note that the latest bluez "not compiled / source" version is 5.50
What I am having trouble with is implementing "bluez" as a development library.
I downloaded the latest "bluez" using this link
http://www.bluez.org/download/
then I followed "README" - basically "configure " and then "install".
Managed to do both without errors. Here are the progress and "issues"
1. I moved the bluez-5.50.tar.xz to a directory and extracted it there. OK
2. Run "./configure ..." within the directory and got tons of tracking messages , too big to post RIGHT NOW. OK
3. Run "sudo make && make install" without getting errors. OK
4. From other sources I should have "bluetooth.x" library SOMEWHERE.
It should be "bluetooth.a" , but I cannot "find …-name..." it.
5. At this point the linker , actually cross linker , references to anything "bluetooth" such as "-lbluethooth" or "-libbluetooth" yields " not found " cross linker error.
6. I can read the ./configure and make outputs but it is hard for me manually find WHERE is the referenced library file.
My BASIC "concept question" is – if I run "install" WHERE would Linux put ANY library , conceptually.
7. I can compile / link "bluetooth" includes – so WHO (Linux OS , bluez) installed them?
As always . I will greatly appreciate any help.
Cheers
Vaclav
modified 20-Mar-19 23:43pm.
|
|
|
|
|
It should: install the library in one of the standard locations. Alternatively if it installs in a private location then some document in the package should tell you where it is. Have a look in /lib /lib64 /usr/lib and /usr/lib64 for the library. You could try something like:
find /lib /lib64 /usr/lib /usr/lib64 -iname '*bluetooth*' -print
Also see if it has been put somewhere else by
echo $LD_LIBRARY_PATH
|
|
|
|
|
I did try this and it looks as
/usr/lib/x86_64-linux-gnu/libbluetooth.a
or
/usr/lib/bluetooth/bluetoothd
maybe the right place
I'll try to link to it
jim@jim-desktop:~$ sudo find /lib /lib64 /usr/lib /usr/lib64 -type f -iname "*bluetooth*" -print
/lib/systemd/system/bluetooth.target
/lib/systemd/system/bluetooth.service
/lib/modules/4.15.0-45-generic/kernel/net/bluetooth/bluetooth_6lowpan.ko
/lib/modules/4.15.0-45-generic/kernel/net/bluetooth/bluetooth.ko
/lib/modules/4.15.0-45-generic/kernel/drivers/platform/x86/toshiba_bluetooth.ko
/lib/modules/4.15.0-43-generic/kernel/net/bluetooth/bluetooth_6lowpan.ko
/lib/modules/4.15.0-43-generic/kernel/net/bluetooth/bluetooth.ko
/lib/modules/4.15.0-43-generic/kernel/drivers/platform/x86/toshiba_bluetooth.ko
/lib/udev/rules.d/50-bluetooth-hci-auto-poweron.rules
/lib/udev/hwdb.d/20-bluetooth-vendor-product.hwdb
/usr/lib/i386-linux-gnu/libbluetooth.so.3.18.10
/usr/lib/bluetooth/bluetoothd
/usr/lib/pm-utils/power.d/usb_bluetooth
/usr/lib/plainbox-provider-checkbox/bin/bluetooth_scan
/usr/lib/plainbox-provider-checkbox/bin/bluetooth_transfer_stress
/usr/lib/plainbox-provider-checkbox/bin/bluetooth_test
/usr/lib/plainbox-provider-checkbox/bin/audio_bluetooth_loopback_test
/usr/lib/x86_64-linux-gnu/libgnome-bluetooth.so.13.0.1
/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so
/usr/lib/x86_64-linux-gnu/libbluetooth.a
/usr/lib/x86_64-linux-gnu/libbluetooth.so.3.18.10
find: ‘/usr/lib64’: No such file or directory
jim@jim-desktop:~$
|
|
|
|
|
This is the archive file: /usr/lib/x86_64-linux-gnu/libbluetooth.a. The other one is probably part of the bluetooth driver (looks like a daemon process). So you need the following options for the linker:
-L /usr/lib/x86_64-linux-gnu -l bluetooth
The first one tells the linker to search that directory, and the second one gives the 'base' name of the archive file.
|
|
|
|
|
does this makes sense ??
jim@jim-desktop:/media/jim/DEV/BLUEZ/bluez-5.50$ sudo make install
make --no-print-directory install-am
/bin/mkdir -p '/usr/local/bin'
/bin/bash ./libtool --mode=install /usr/bin/install -c client/bluetoothctl monitor/btmon tools/rctest tools/l2test tools/l2ping tools/bccmd tools/bluemoon tools/hex2hcd tools/mpris-proxy tools/btattach '/usr/local/bin'
libtool: install: /usr/bin/install -c client/bluetoothctl /usr/local/bin/bluetoothctl
libtool: install: /usr/bin/install -c monitor/btmon /usr/local/bin/btmon
libtool: install: /usr/bin/install -c tools/rctest /usr/local/bin/rctest
libtool: install: /usr/bin/install -c tools/l2test /usr/local/bin/l2test
libtool: install: /usr/bin/install -c tools/l2ping /usr/local/bin/l2ping
libtool: install: /usr/bin/install -c tools/bccmd /usr/local/bin/bccmd
libtool: install: /usr/bin/install -c tools/bluemoon /usr/local/bin/bluemoon
libtool: install: /usr/bin/install -c tools/hex2hcd /usr/local/bin/hex2hcd
libtool: install: /usr/bin/install -c tools/mpris-proxy /usr/local/bin/mpris-proxy
libtool: install: /usr/bin/install -c tools/btattach /usr/local/bin/btattach
/bin/mkdir -p '/usr/local/libexec/bluetooth'
/bin/bash ./libtool --mode=install /usr/bin/install -c src/bluetoothd obexd/src/obexd '/usr/local/libexec/bluetooth'
libtool: install: /usr/bin/install -c src/bluetoothd /usr/local/libexec/bluetooth/bluetoothd
libtool: install: /usr/bin/install -c obexd/src/obexd /usr/local/libexec/bluetooth/obexd
/bin/mkdir -p '/usr/local/lib/cups/backend'
/bin/bash ./libtool --mode=install /usr/bin/install -c profiles/cups/bluetooth '/usr/local/lib/cups/backend'
libtool: install: /usr/bin/install -c profiles/cups/bluetooth /usr/local/lib/cups/backend/bluetooth
/bin/mkdir -p '/etc/dbus-1/system.d'
/usr/bin/install -c -m 644 src/bluetooth.conf '/etc/dbus-1/system.d'
/bin/mkdir -p '/usr/share/dbus-1/services'
/usr/bin/install -c -m 644 obexd/src/org.bluez.obex.service '/usr/share/dbus-1/services'
/bin/mkdir -p '/usr/share/dbus-1/system-services'
/usr/bin/install -c -m 644 src/org.bluez.service '/usr/share/dbus-1/system-services'
/bin/mkdir -p '/usr/local/share/man/man1'
/usr/bin/install -c -m 644 tools/rctest.1 tools/l2ping.1 tools/bccmd.1 tools/btattach.1 tools/hid2hci.1 '/usr/local/share/man/man1'
/bin/mkdir -p '/usr/local/share/man/man8'
/usr/bin/install -c -m 644 src/bluetoothd.8 '/usr/local/share/man/man8'
/bin/mkdir -p '/lib/udev/rules.d'
/usr/bin/install -c -m 644 tools/97-hid2hci.rules '/lib/udev/rules.d'
/bin/mkdir -p '/lib/systemd/system'
/usr/bin/install -c -m 644 src/bluetooth.service '/lib/systemd/system'
/bin/mkdir -p '/usr/lib/systemd/user'
/usr/bin/install -c -m 644 obexd/src/obex.service '/usr/lib/systemd/user'
/bin/mkdir -p '/lib/udev'
/bin/bash ./libtool --mode=install /usr/bin/install -c tools/hid2hci '/lib/udev'
libtool: install: /usr/bin/install -c tools/hid2hci /lib/udev/hid2hci
jim@jim-desktop:/media/jim/DEV/BLUEZ/bluez-5.50$
|
|
|
|
|
As a package install it looks OK, but as it is not something I am familiar with I can't really say whether it's correct or not.
|
|
|
|
|
still no go.
Not sure where is the liker looking for the "bluetooth".
I am including edited , FOR MOST PART DELETED , linker verbose output.
Maybe the crosslinking process needs help , more options. I just do not know.
Perhaps the highlighted part could help to figure this out.
Building target: VNAR_19350
Invoking: Cross G++ Linker
arm-linux-gnueabihf-g++ -L/media/jim/DEV/BLUEZ/BlueZ-5.50 -L/usr/lib/bluetooth/bluetoothd -L/usr/lib/bluetooth -L/usr/local/libexec/bluetooth/ -v -o "VNAR_19350" ./src/MODULES/SOURCE_CODE/src/ESA_BASE_BAD.o ./src/MODULES/M_WIRE/CLASSWIRE.o ./src/MODULES/M_VNARODULE_1602/C_SPI_LCD.o ./src/MODULES/MODULE_1602/C_SSP.o ./src/MODULES/MODULE_1602/C_gpio.o ./src/VNA_1022_BASE.o -lbluetooth.a -lbluetoothd -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.a
/usr/lib/gcc-cross/arm-linux-gnueabihf/5/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lbluetoothd
collect2: error: ld returned 1 exit status
make: *** [VNAR_19350] Error 1
makefile:80: recipe for target 'VNAR_19350' failed
"make all" terminated with exit code 2. Build might be incomplete.
I did use
-L /usr/lib/x86_64-linux-gnu -l bluetooth
and got a message about "invalid" file type - it tried to link to "libbluetooth.o"
I could go back and try that again and post the output if it helps.
|
|
|
|
|
5. At this point the linker , actually cross linker , references to anything "bluetooth" such as "-lbluethooth" or "-libbluetooth" yields " not found " cross linker error.
There's the problem. On your X86_64 box, you've installed bluez-X86_64. The linker will not link an X86_64 lib into an ARM target. Your X86_64 linux distribution may provide a libbluetooth-devel-arm package that will work with the cross compiler, but I doubt that.
I've just been poking about on my rpi-2 (raspian-debian jessie), and I think the following might work for you. Note that if you're on a pi3 or using something other jessie, things will be slightly different.
on the pi:
sudo apt-get install -d libbluetooth-dev
The -d flag downloads the package and puts it in /var/cache/apt/archives/, but doesn't actually install it. I see there's a lot of files there, so it might be worth checking to see if you've already got the package there already. On my system its libbluetooth-dev_5.23-2+rpi2_armhf.deb, so I expect yours will be similar.
on the X86_64, we'll assume that you've got a $HOME/tmp that you will use for copying and you will put the package contents in $HOME/rpi. Vary as necessary in the following:
cd $HOME/tmp
scp pi@10.0.1.76:/var/cache/apt/archives/libbluetooth-dev_5.23-2+rpi2_armhf.deb
mkdir $HOME/rpi
cd $HOME/rpi
dpkg -x $HOME/tmp/libbluetooth-dev_5.23-2+rpi2_armhf.deb
This will unpack the contents of the libbluetooth-dev package in the current directory. You should now have usr/include, usr/lib and usr/share in the $HOME/rpi directory, and you can now remove $HOME/tmp/libbluetooth-dev_5.23-2+rpi2_armhf.deb file. If you check your $HOME/rpi/lib/arm-linux-gnueabihf directory, you will probably find a broken link for libbluetooth.so. If you're happy just using the static linked .a library, you can delete the broken link. If you'd like to use the shared library, then scp /usr/lib/arm-linux-gnueabihf/libbluetooth.so.3.17.1 from the pi to $HOME/pi/lib/arm-linux-gnueabeihf (once again things may be different if you're on a different OS version than me).
Now add flags for -I $HOME/rpi/usr/include and -L$HOME/rpi/usr/lib/arm-linux-gnueabihf -lbluetooth to your IDE. (check the last part of the -L path if not on jessie). This way, at least, you have the same includes and libs available to your cross compiler as you have on the pi, but you'll have to remember to update the X86_64 if you update the bluetooth package on the pi.
Now, I haven't tried this, beyond unpacking the pi package (on the pi...) so it might not work, but I think it should. If there are any dependencies that libbluetooth-dev has that are needed, you'll need to repeat this process with them, too.
If this doesn't work, you may have to use the crosscompiler to build libbluetooth (and any of its dependencies).
Update:
I have had a chance to try this out, and can confirm it should work. Not knowing where to start with libbluetooth, I wrote a short ncurses program which I was able to cross-compile using the technique above and run on my rpi. I did run into an issue where libncurses has a dependency on libtinfo, so I had to track that down and add it to my $HOME/rpi, so you may have to do the same with any dependencies libbluetooth might have.
modified 5-Mar-19 20:22pm.
|
|
|
|
|
Thanks, just to make sure I understand .
You are saying the problem is crosscompiling on X86 to ARM the resultant bluez "library", build on X86 by the process I am using , cannot be used.
Since this is my first compile for Linux I cannot comment on that.
Two things are little bothersome - why am I getting "unable to find" - should the crosscomplier post a better descriptive error?
I am under the impression that it is the purpose of crosscompliler - to manage DIFFERENT OS / hardware.
Perhaps the difference is in crosscompling C++ source on X86 ( to ARM) as oppose utilizing / linking already complied (X86 libray) on different hardware as you pointed out.
But all this is still done on X86 - only the result executable is passed to ARM.
OR is the linking done on ARM? That is confusing.
In any case I'll try your approach.
Thanks
|
|
|
|
|
Vaclav_ wrote: You are saying the problem is crosscompiling on X86 to ARM the resultant bluez "library", build on X86 by the process I am using , cannot be used.
That is correct. You do have a cross-compiler, so you could build the library using that compiler to get an ARM compatible library. In order to do that you would need to let make know to use the cross compiler. On my system that would be:
$ export CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++
$ configure --prefix=/usr/local/arm ...
$ make
$ sudo make install
Most packages use a configure, make, make install routine, but some use cmake to configure make. There's usually an install doc with any source tarball that will tell you how to build the package, and what dependencies are needed.
Vaclav_ wrote: why am I getting "unable to find" - should the crosscomplier post a better descriptive error?
I'm not sure what you'd like the linker to do. When using the cross-compiler, that runs the cross-linker which looks in standard places and any provided search paths (-L flags) for the cross linker for libraries. The linker doesn't know whether -lbluetooth is a valid library name or not, just as it doesn't know if -lbleutoof is a valid library name or not.
Vaclav_ wrote: I am under the impression that it is the purpose of crosscompliler - to manage DIFFERENT OS / hardware.
And that is what it is trying to do, but it does need target specific libraries to be able to complete its work.
Lets take a few steps back. Suppose we have the following code
$ cat hello.h
#ifndef HELLO_H
#define HELLO_H
void hello(void);
#endif
$ cat hello.c
#include <stdio.h>
#include "hello.h"
void hello()
{
printf("hello wolrd\n");
}
$ cat main.c
#include "hello.h"
int main()
{
hello();
return 0;
} That's just a simple "hello world" C program broken up into 2 parts, a main.c and a hello.c with its associated hello.h
working on the X86 we can compile the pieces and then link in two steps as follows:
$ gcc -Wall -Wextra -c main.c hello.c
$ gcc main.o hello.o -o hello.x86
$ file *.o hello.x86
hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
hello.x86: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=016de8ea587d3a1294bc3c2221aea11cba37c97f, not stripped The -c tells gcc to compile the .c files and produce .o files, but don't link everything together. The linking we do in the second command, and all works as expected.
Now suppose we delete the main.o and try to use the cross-compiler to create a main.o and then link everything together:
$ rm main.o
$ arm-linux-gnu-gcc -Wall -Wextra -c main.c
$ file main.o hello.o
main.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), not stripped
hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
$ arm-linux-gnu-gcc main.o hello.o -o main.arm
/usr/bin/arm-linux-gnu-ld: i386:x86-64 architecture of input file `hello.o` is incompatible with arm output
/usr/bin/arm-linux-gnu-ld: hello.o: file class ELFCLASS64 incompatible with ELFCLASS32
/usr/bin/arm-linux-gnu-ld: final link failed: File in wrong format
collect2: error: ld returned 1 exit status
We can see that the format of the two .o files is different one is ELF-32bit for ARM and the other is ELF-64bit for X86_64. These are incompatible object formats, so we should not be surprised that they do not link together.
The difference between the simple hello.o file, above, and a library (either a .so or a .a) is that the library is, if you like, just a bundle of .o files. When linking to a library, what the linker does, in essence, is extract the object (.o) files from the library and links them into the executable (for shared libraries [.so files] its a little different, in that the linker only needs to insert into the executable the binding information for any called fuctions, but the idea is similar).
Vaclav_ wrote: But all this is still done on X86 - only the result executable is passed to ARM.
OR is the linking done on ARM? That is confusing.
All the compiling and linking is done on the X86. If you were to shutdown the pi, the compilation and linking would still proceed in exactly the same manner.
|
|
|
|
|
Thanks for update.
I had few detours but now I have the correct package installed on RPi.
Will call it quits for tonight.
Later
Late night add
Looks as libbluetooth-dev by itself is available for different architecture.
I'll check that.
It also looks as "bluez" is NOT development package.
More confusion.
New addendum
I am not sure how to continue this thread.
I really need better understanding the general relations between Linux OS and anything related to bluetooth.
From this source BlueZ » Download[^]
it looks as Linux (kernel) contains "module" to interact with bluetooth.
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?
Why would one care where is the "bluez" physically?
OS should take care of that.
Now "bluez" can be installed into "user space".
And used for what ?
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?
I am going to take a look at the above link "configure" to see if it can be optioned for specific architecture.
modified 6-Mar-19 9:17am.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
