|
using --prefix=/usr put all the generated files in /usr. If you still have your build directory, you should be able to remove everything with using make uninstall. If you've already deleted your build directory, then unpack the source again, re-run configure as you did before, then run make uninstall. Note that installing into /usr means that you've overwritten anything that apt installed previously, so you might end up with the apt thinking thinking that some of its files have gone missing. If you plan to build a cross-compilation library DO NOT USE --prefix=/usr. That will overwrite the X86 executables, libraries, etc with the ARM versions, which will lead to further pain on your part. If you still want to create a cross-compile bluez instalation, use --prefix=/usr/local/arm --sysconfdir=/usr/local/arm/etc --localstatedir=/usr/local/arm/var. Of course, you can use any path you wish in place of "/usr/local/arm", just not "/usr" or "/", as that will overwrite your X86 system files.
|
|
|
|
|
Am I correct to say that /usr is a common Linux directory ,used by other applications?
So I should be able to "insert " another directory - such as --prefix=/usr/X86 for the X86 architecture and --prefix =/usr/ARM for the ARM?
Such as you suggested using /usr/local/arm....?
What would be the advantage of inserting ../local/ ..?
I should take a look at "configure prefix".
|
|
|
|
|
There's no reason you can't use /usr/X86 and /usr/ARM, if that's your wish, its not likely to cause problems for your linux system. In general, though, its a convention, nothing more, to put user-compiled software in /usr/local. If you run .configure for most software packages they default to --prefix=/usr/local. I suggested /usr/local/arm as that fits in with the accepted convention. Ultimately, you have root permissions, and can put things where you like. The one caveat, though, is if you put things in /[bin|lib], or /usr/[bin|lib] you run the risk of a) making your system unusable due to overwriting system provided executables or libraries with incompatible version and b) having your executables and libs reverted back to OS versions when updating software. For me, I think I'd put anything new I compiled for the X86 in /usr/local, as the compiler and linker will search /usr/local/include and /usr/local/lib, without having to add -I/usr/local/include or -L/usr/local/lib to compilation commands. I think /usr/local/arm or /usr/local/pi seems a reasonable location to put the ARM versions.
|
|
|
|
|
Another thing: If you have a successful compile/link AND you're linking shared libraries (.so), you can find out which version of the library will be used using the ldd command
e.g
rpi:~$ ldd /usr/bin/find
linux-vdso.so.1 (0x7eff1000)
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76f53000)
libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x76f0c000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e8d000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76d4e000)
/lib/ld-linux-armhf.so.3 (0x76f69000)
libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x76cd5000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76cc2000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76c99000)
|
|
|
|
|
Nice , but now I know which library was build by package and thatit the one linker will use so I do not have to search for it.
|
|
|
|
|
I am beginning to wonder if Linux "Open (source) " is really beneficial.
The following code snippet just stops executing, and I get no perror.
I like to analyze the source code for "hci_inquiry" function to get some idea way it is failing.
num_rsp = hci_inquiry(dev_id, len, max_rsp, NULL, &ii, flags);
if (num_rsp < 0)
perror("Error: hci_inquiry");
.
I have found numerous versions / copies of BlueZ docs with this preamble
* BlueZ - Bluetooth protocol stack for Linux
*
* Copyright (C) 2000-2001 Qualcomm Incorporated
* Copyright (C) 2002-2003 Maxim Krasnyansky <maxk@qualcomm.com>
* Copyright (C) 2002-2010 Marcel Holtmann <marcel@holtmann.org>
*
*
MOST of them lack comments describing the function I am after.
My question to forum users :
Which Linux resource , in general , is most likely to be updated and best documented?
Github?
|
|
|
|
|
Vaclav_ wrote: Which Linux resource , in general , is most likely to be updated and best documented?
The one that is. Seriously, the only way to find out is to look at them all. My idea of 'best' may not tally with yours.
|
|
|
|
|
|
This is not a question , just sort of FYI if anybody cares.
Instead of futzing with crosscomplier I have decided to build a local bluetooth application.
I have purged "bluez" from my X86 system.
I have left the "-lbluetooth" linker option intact.
I can compile / link and run the app and get expected errors from accessing basic stuff - such as
dev_id = hci_get_route(NULL); if (dev_id < 0) {
perror("Bluetooth device not found"); }
Next I'll be reinstalling / configuring / make / make install "bluez" , again.
In theory that should get rid of most of the errors without touching the "-lbluetooth" option.
|
|
|
|
|
The following TEST snippet works just fine, however, since the "hci_inquiry" itself generate the expected perror why does the code continues to run and not exiting AFTER "hci_inquiry"?
It does exits AFTER the last test of num_rsp, as expected.
num_rsp = hci_inquiry(dev_id, len, max_rsp, NULL, &ii, flags);
if( num_rsp < 0 ) perror("Error: hci_inquiry");
if( num_rsp < 0 ) perror(NULL);
Here is the expected output:
Error: hci_inquiry: No such device
No such device
hci_inquiry: No such device
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
