|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
According to my reading of the documentation that should work, so I am afraid I have no more ideas.
|
|
|
|
|
You may or may not have access to a GRUB environment block (of which you make no mention).
Quote: For safety reasons, this storage is only available when installed on a plain disk (no LVM or RAID), using a non-checksumming filesystem (no ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).
grub-mkconfig uses this facility to implement ‘GRUB_SAVEDEFAULT’ (see Simple configuration).
GNU GRUB Manual 2.06
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Quote: The environment block is a preallocated 1024-byte file, which normally lives in /boot/grub/grubenv (although you should not assume this). At boot time, the load_env command (see load_env) loads environment variables from it, and the save_env (see save_env) command saves environment variables to it. From a running system, the grub-editenv utility can be used to edit the environment block.
GNU GRUB Manual 2.06: Environment block
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
I just tried this and it works correctly. Whatever is happening on your system is unique to you, and may have something to do with previous questions which suggest that your installation is not very stable.
|
|
|
|
|
Isn't this something you can see from the source code?
That's the the great advantage of open source projects: If the system doesn't behave the way you want it to, you have the full freedom to go into the source code and modify it the way you want.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: As a "user" why should I (have) to do that ?
Because it is Free and Open Source Software.
It is given to you so that you can fix it yourself. That is what the free-ness and open-ness is about. You may of course ask your friends to fix it for you, or even pay someone to fix it (although that sort of kills the "free" idea, at least in the sense of "free beer").
When you accept a "free" offer that is financed by ads and commercials, then you are the product being sold.
When you accept "free" and open sources software, then you are the maintainer of that software.
This is 101 FOSS.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Member 14968771 wrote: for example "device_desc" and "dd" are same...
Maybe, but that is not a rule that you can rely on.
|
|
|
|
|
Message Closed
modified 15-May-23 19:06pm.
|
|
|
|
|
Short answer is you don't need to know. When linking your program with -lbluetooth should be enough, if it's installed in the usual place. Depending on what your development environment is, you can use pkg-config to tell you what flags you need to use to find headers and libs e.g
k5054@localhost:~$ pkg-config --cflags bluez
k5054@localhost:~$ pkg-config --libs bluez
-lbluetooth
k5054@localhost:~$ This tells us that we don't need any additional flags for compilation, and only need to add -lbluetooth when linking.
If you really want to know where the lib is, you can use dpkg to tell you where it is
k5054@localhost:~$ dpkg -S libbluetooth | grep .so
libbluetooth3:amd64: /usr/lib/x86_64-linux-gnu/libbluetooth.so.3
libbluetooth3:amd64: /usr/lib/x86_64-linux-gnu/libbluetooth.so.3.19.3
libbluetooth-dev:amd64: /usr/lib/x86_64-linux-gnu/libbluetooth.so
k5054@localhost:~$ Note that debian/ubuntu uses the target architecture as part of the filename for libraries, so for a PI with a 32 bit Raspberry Pi OS, the path is /usr/lib/arm-linux-gnueabihf/libbluetooth.so.3, and it would be different again for a PI with a 64-bit OS, or an i386, MIPS, etc.
Keep Calm and Carry On
|
|
|
|
|
Member 14968771 wrote: The following NEW packages will be installed:
libbluetooth-dev
So the option to use in your build should be -lbluetooth-dev. But you also need to check that it is installed in one of the automatically searched locations. The names of these will be in the environment variable LD_LIBRARY_PATH. If the library is not in one of those places then you can:
1. Add its name to the envoronment variable, or
2. Use the -L option on the build.
|
|
|
|
|
|
Message Closed
modified 15-May-23 19:07pm.
|
|
|
|
|
Member 14968771 wrote: PLEASE help me with link to real "blueZ" instructions ( NOT the original link,
Since you have not told us which one does not work, I assume you meant the one at bluez.org. So maybe try Bluetooth Management | Ubuntu[^].
|
|
|
|
|
What's wrong with the bluez package shipped with your distribution? You can install the package using apt install libbluetooth-dev for debian based distributions (Debian, Ubuntu, PI OS, etc), or dnf install bluez-libs-devel for RedHat based distributions. There also seems to be bluez packages that are targeting QT, so those might be useful to you, too.
Update: If you insist on building from source, you need to generate your own configure script from the included configure.ac. The INSTALL document mentions that you should build this using autoconf, but if you try that you'll probably get something like
$ autoconf
configure.ac:5: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:11: error: possibly undefined macro: AM_MAINTAINER_MODE
configure.ac:24: error: possibly undefined macro: AM_PROG_CC_C_O
configure.ac:25: error: possibly undefined macro: AC_PROG_CC_PIE
configure.ac:26: error: possibly undefined macro: AC_PROG_CC_ASAN
configure.ac:27: error: possibly undefined macro: AC_PROG_CC_LSAN
configure.ac:28: error: possibly undefined macro: AC_PROG_CC_UBSAN
configure.ac:35: error: possibly undefined macro: AC_DISABLE_STATIC
configure.ac:36: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:44: error: possibly undefined macro: AM_CONDITIONAL What you ned to do instead is use autoreconf --install. This will build a new configure script which you can then use to build the bulez library.
Keep Calm and Carry On
modified 13-Mar-22 14:23pm.
|
|
|
|
|
I recently installed ubuntu on a spare computer (Surface Pro 3)and have been playing with it.
I'm familiar with Linux in general and used it extensively in the past.
Now I need to get some programming done, specifically desktop engineering apps wit graphics, like graph and fluidstreamline map displays.
What is the best IDE for that purpose? I foresee most coding will be in c/c++.
CQ de W5ALT
Walt Fair, Jr.PhD P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
I haven't done C++ development on Linux but eventually hope to, at which point I'll probably go for this: Running Visual Studio Code on Linux[^]. A lot of folks on this site like VS Code, but I'm still on VS2022, mostly because my project has over 800 source files and I don't want to bang my head against a new build process.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
