Linux Programming

Richard MacCutchan3-Mar-19 5:53

3-Mar-19 5:53

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.

Vaclav_3-Mar-19 7:08

3-Mar-19 7:08

Thanks
I'll take a look at the log.
I a hAve never done that so it will take a while.

k50543-Mar-19 6:03

3-Mar-19 6:03

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.

Vaclav_3-Mar-19 7:09

3-Mar-19 7:09

See my last reply.

k50543-Mar-19 6:32

3-Mar-19 6:32

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.

Vaclav_3-Mar-19 7:05

3-Mar-19 7:05

Thanks.
I was aware that I was getting only current directory finds.
I did modify the CL , but now I am getting only directories.

C++

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:~$

Vaclav_3-Mar-19 7:15

3-Mar-19 7:15

I think I need to link , using "_L" option to highlighted file and its directory.

C++

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" ??

C++

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.

k50543-Mar-19 7:44

3-Mar-19 7:44

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.

Vaclav_3-Mar-19 8:12

3-Mar-19 8:12

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.

C++

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.

k50543-Mar-19 9:04

3-Mar-19 9:04

No. Its not -lfopenmp, it is -fopenmp.

Given this hello.cpp:

C++

#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!

Richard MacCutchan3-Mar-19 21:34

3-Mar-19 21:34

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.

Vaclav_4-Mar-19 4:28

4-Mar-19 4:28

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.

Richard MacCutchan4-Mar-19 4:56

4-Mar-19 4:56

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.

k50544-Mar-19 7:42

4-Mar-19 7:42

Looks like you learn something new every day (unless you're careful Smile | :)

). 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.

Richard MacCutchan4-Mar-19 9:47

4-Mar-19 9:47

$ 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.

k50544-Mar-19 12:45

4-Mar-19 12:45

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.

Richard MacCutchan4-Mar-19 21:44

SOLVED system call syntax ?

4-Mar-19 21:44

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.

Vaclav_7-Feb-19 6:40

7-Feb-19 6:40

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

C++

#include <omp.h>

// Get the number of processors in this system
	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.

k50547-Feb-19 8:02

7-Feb-19 8:02

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?

Vaclav_7-Feb-19 10:23

7-Feb-19 10:23

This is response from CL on my PC

jim@jim-desktop Unsure | :~

$ omp_get_num_procs()
>

and this is coming from RPi

pi@pi Unsure | :~

$ jim@jim-desktop Unsure | :~

$ omp_get_num_procs()
-bash: syntax error near unexpected token `('
pi@pi Unsure | :~

$ >
-bash: syntax error near unexpected token `newline'
pi@pi Unsure | :~

$ sudo omp_get_num_procs()

The purpose / reason was posted in OP.

-bash: syntax error near unexpected token `('
pi@pi Unsure | :~

$ sudo omp_get_num_procs
sudo: omp_get_num_procs: command not found
pi@pi Unsure | :~

$

I'll check the man.

k50547-Feb-19 11:20

7-Feb-19 11:20

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()?

Richard MacCutchan7-Feb-19 22:26

7-Feb-19 22:26

You do not need parentheses on command/program calls in the system. Change your code to:

C++

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.

Vaclav_8-Feb-19 3:23

8-Feb-19 3:23

C++

int main() {
#ifdef STEP
	cout << "Project VNAR-19270 VNA-1023 (6 base) Vector network analyzer" << endl; 
	cout << "DEBUG ****RUNNING WORKING COPY of VNA_2 " << endl; 
	//exit(1);
#endif



	// Get the number of processors in this system
	int iCPU = 0;
	iCPU = system ("omp_get_num_procs");
	cout << "# of CPU's " << dec << +iCPU << endl;
	exit(1);

Now returns omp_get_num_procs not found.
I think the problem is also in crosscompiler settings.
Also the "remote AKA RPi" OS has no OpenMP installed.
I need to check that.

I was just looking for an advise if my syntax is OK.

Richard MacCutchan8-Feb-19 4:56